Solveurs distribués

L’usage de solveurs distribués permet de traiter un problème, dont le domaine est décomposé, sensiblement de la même manière que le cas séquentiel. Autrement dit, un système algébrique global est construit et fourni au solveur pour être résolu. Puisque toutes les communications sous-jacentes à la résolution sont encapsulées dans le solveur, cette approche requiert norma- lement un effort de programmation moindre de la part de l’utilisateur. Toutefois, ce dernier doit gérer la construction d’un système global mais distribué sur les processus. Des indices locaux et globaux doivent alors être définis pour les DDLs ainsi qu’une méthode pour traduire les indices d’un ensemble à l’autre [23].

Plusieurs solveurs distribués sont disponibles en libre accès. Dans le domaine des solveurs itératifs, la bibliothèque d’algèbre linéaire PETSc [24] représente l’état de l’art dans l’implé- mentation des méthodes de Krylov. Trilinos [25] et Hypre [26] sont des bibliothèques, parmi tant d’autres, offrant des méthodes de résolutions itératives. Ces solveurs bénéficient d’un parallélisme MPI mais ne supportent généralement pas, ou dans un cadre limité, l’usage de threads OpenMP. En ce qui concerne les méthodes directes, les solveurs Mumps [27], Cluster Pardiso de Intel [28]2 _{et la version disribuée de SuperLU [29] sont les options les plus cou-} rantes [30, 31]. Les performances de ces derniers sont généralement optimales lorsqu’ils sont utilisés dans un context hybride MPI/OMP.

Nous ne nous attarderons pas sur la mécanique interne de ces solveurs. Notre objectif est plutôt de présenter leur modes d’utilisation et plus spécifiquement, les formats des matrices requises par certains d’entre eux. Nous nous attarderons plus spécifiquement aux solveurs Cluster Pardiso de Intel, Mumps ainsi que l’interface offerte par PETSc.

Cluster Pardiso

Comme son nom l’indique, le solveur direct CPardiso est une version de Pardiso, incorpo- rant le protocole MPI, pouvant être exécuté depuis une plateforme à mémoire distribuée. Il

conserve également le parallélisme multithread de sa version originale, lui conférant typique- ment un maximum de performance lorsqu’il est utilisé dans un paradigme hybride de style funneled [32].

Son mode d’emploi est, à toute fin pratique, identique à celui de Pardiso. En effet, les ap- pels au solveur, pour les différentes phases de calcul, se font tous à partir de la méthode cluster_sparse_solver3. Cette dernière prend en entrée les arguments suivants :

— Mtype : Définit le type de matrice (symétrique, définie positive, complexe, etc) ; — Phase : Définit le type de calcul (analyse, factorisation, résolution) à exécuter ; — Ai, Aj, Ax, B : Les structures décrivant le système d’équations ;

— Iparm : Contrôle des paramètres ; — Comm : Communicateur MPI ;

Toutes les options fournies au solveur sont définies dans le vecteur Iparm. Ces dernières sont les mêmes que pour Pardiso à l’exception des cases 1 et 39-41.

Iparm[39] définit le format de matrice en entrée. Il est possible de fournir une matrice CSR (Compressed Sparse Row) depuis un processus unique ou une matrice DCSR (Distributed Compressed Sparse Row) depuis tous les processus. Ces dernières sont présentées ci-dessous. Le format CSR décrit la structure et le contenu d’une matrice creuse, à l’aide des trois vecteurs Ap, Aj et Ax, de manière à ce que les coefficients d’une même ligne soit contigus en mémoire et classés, en ordre croissant, par l’index de leur colonne. Les vecteurs Aj et Ax, de longueur nnz, le nombre de coefficient non nuls, renferment respectivement les indices des colonnes et les valeurs des coefficients. Le vecteur Ap, d’une taille nL équivalente au nombre de lignes de la matrice, contient la position du premier coefficient de chaque ligne.

La version distribuée de ce format consiste simplement à répartir les lignes de la matrice parmi les processus, en sous-ensembles contigus. Chaque processus possède donc une matrice locale CSR A(i) _≡ n_A(i)

p , A (i) j , A(i)x

o

où A(i)_j contient les indices globaux des colonnes. Lorsque ce format est choisi, CPardiso requiert que les indices de la première et dernière lignes des matrices locales soient donnés en Iparm[40] et Iparm[41].

Iparm[1] permet de sélectionner une méthode de réordonnancement parmi un algorithme séquentiel, multithread ou distribué. Pour les deux premiers choix, l’analyse est exécutée uniquement sur le processus maître. Si la matrice est de type DCSR, elle est également centralisée sur ce processus. Dans cette situation, rien n’empêche les matrices locales de se chevaucher, car CPardiso se charge d’additionner les contributions des lignes partagées par

plusieurs processus. En ce qui concerne l’algorithme distribué, la matrice n’est pas centralisée et diminue considérablement le coût en mémoire.

Mumps

Mumps est également un solveur direct profitant d’une parallélisation MPI et OpenMP. Par rapport aux fonctionnalités et aux arguments d’entrée, ce solveur est très similaire à CPardiso. Toutefois, il existe des différences majeures en ce qui concerne le format de la matrice ainsi que la distribution des vecteurs solution et RHS. En effet, Mumps requiert une matrice dans un format COO (Coordinates). Cette dernière décrit les coefficients d’une matrice A à l’aide de trois vecteur Ai, Aj, Ax, de longueur nnz, où Ai renferme les indices de ligne pour tous les coefficients. Comparativement au format CSR, ce format est moins compact et plus difficile à manipuler. Néanmoins, les coefficients peuvent être incorporés dans la matrice dans n’importe quel ordre. Pour une matrice distribuée, ce format possède la propriété qu’une matrice locale A(i) peut inclure n’importe quel coefficient, peu importe sa position dans la matrice globale. Bien que le format de matrice confère un maximum de flexibilité, il n’en est pas de même pour le membre de droite. Ce dernier doit être centralisé sur le processus maître. En ce qui concerne le vecteur solution, Mumps a la possibilité de le stocker entièrement sur le processus maître ou de manière distribuée. Dans le second cas, la répartition du vecteur est définie par les structures internes de Mumps et ne correspond généralement pas à l’indexation propre à l’application.

PETSc

PETSc est une bibliothèque mutli-fonctionnelle. Son module KSP (Krylov SubSpace) permet d’utiliser des solveurs itératifs aussi bien que certains solveurs directs. Dans les deux cas, le système linéaire est construit à partir des objets distribués mat et vec.

En réalité, PETSc offre plusieurs formats possibles de matrice distribuée, mais nous ne consi- dérons ici que le type mpiaij. Ce format est similaire au format DCSR. Cependant, les diffé- rents processus ne peuvent pas partager les mêmes lignes comme c’est le cas avec CPardiso. De plus, les colonnes sont également partitionnées en sous-ensembles continus pour former des blocs diagonaux et hors diagonaux tel qu’illustré à la figure 4.2. Concrètement, chaque processus conserve les coefficients de son bloc diagonal dans une matrice CSR et ceux des blocs hors diagonaux dans une autre matrice CSR.

Les structures de PETSc permettent à un processus d’insérer un élément situé sur une ligne appartenant à un autre processus. À l’interne, un processus possède une liste dynamique de

D D D HD HD HD HD HD HD Processus 0 Processus 1 Processus 2

Figure 4.2 Structure par blocs diagonaux et hors diagonaux des matrices PETSc

coefficients à envoyer aux autres processus. Dès qu’un processus reconnaît qu’un coefficient n’est pas local, il le place à la fin de la liste. Les communications se font depuis les appels aux fonctions MatAssemblyBegin et MatAssemblyEnd. Ensuite, la liste est réinitialisée.