sition algorithms. The 2-level parallel implementation will be effective for our hybrid solver if its main three phases can be efficiently performed in parallel. Let us quickly recall the main numerical kernels of our algorithm and for each of them describe the parallel strategy.
Initialization phase1
The idea of the 2-level parallel method is to handle each subdomain using several processors. To allow multi-processing per subdomain, the algorithm should control several groups of processors, each of them working on different tasks associated with the subdomains. We define as many groups as subdomains and associate one MPI-communicator with each of them. As result, we perform simultaneously each local factorization in parallel taking the advantage of the sparse direct solver in a grid of processors (group). The computed Schur matrix is stored over the grid processors according to the 2D block-cyclic data distribution.
Preconditioner setup phase2
The local Schur complements are dense and distributed over the processor grid. This means that each processor stores blocks of rows and columns of the “local" Schur complement. Because pro- cessors must exchange data during the assembly step, the cost of this latter must be considered. This step does not depend on the number of processors and depend only on the number of neighbouring subdomains. We notice that, for the large simulations, the local Schur matrices are large. For the standard 1-level parallel algorithm, only one processor has to communicate with its neighbouring subdomain/processor in order to assemble the local Schur matrix. In a multi-level parallel frame- work, we have to pay attention to perform this phase efficiently. For this purpose, each processor that stores part of the “local" Schur knows the identity of the processors handling the corresponding part of the neighbouring “local" Schur complements to have efficient point-to-point communication. This enables parallel communication and assembling of the preconditioner.
Iterative loop phase3
This phase involves three numerical kernels that are: the matrix-vector product, the preconditioner application and finally the global reduction step. The local Schur matrices are distributed over the local grid of processors so that both PBLASand ScaLAPACKcan be used easily.
For the matrix-vector product, the implementation is performed using the PBLAS routines to multiply the dense distributed local Schur complement with also the distributed vector uk. The resulting distributed vector is updated directly between neighbouring subdomains as each processor associated with one subdomains knows its neighbours associated with neighbouring subdomains.
The preconditioner application relies either on ScaLAPACKkernels for the dense Md−64 precon-
ditioner or MUMPSfor the sparse Msp−64 preconditioner. Similarly to the matrix-vector product,
the resulting distributed vector is updated.
For the dot product calculation, each processor owning the distributed vectors performs its local dot product then the results are summed using a simple global reduction.
Because each step can be parallelized, the iterative loop calculation greatly benefits from the
2-level parallel implementation.
We summarize in Algorithm10, the main algorithmic steps of our 2-level parallel implementa- tion. The complexity of the actual code is of course by no means reflected by these few lines of algorithmic description.
50 Design of parallel distributed implementation
Algorithm 10 2-level parallel method implementation 1: Define a set of groups of processors.
2: Define communicators for groups, masters of groups.
3: Initialize BLACSenvironments
4: if (I am Master of group) then
5: Partition problem into N subdomains (or generate N subdomains)
6: end if
7: Define new data-structure and new sub-indexing of variables
8: Simultaneously initialize parallel instance (over the grid processors) of direct solver
9: Perform on each subdomain parallel factorization and computation of the Schur complement.
10: Assemble local Schur complement 2D block-cyclic data distribution
11: Setup the preconditioner locally in parallel
12: if (I am Master of group) then
13: Distribute the RHS over the column grid of processors
14: end if
15: Perform the iterative loop
16: for k= 1, convergence do
17: Perform matrix-vector product in parallel over the grid processors yi←
S
ixi18: Column processors communicate the value of the result y←
nbneighbour
∑
1
R
Γiyi19: Perform preconditioner applications
20: Column processors communicate the value of the result y←
nbneighbour
∑
1
R
Γiyi21: Perform dot product by the column processor. 22: end for
23: if (I am column processor or Master of group) then 24: Scatter the interface solution
25: end if
Part II
Study of parallel scalability on large
Part II: résumé
Dans ces deux chapitres, nous allons illustrer le comportement numérique et les performances parallèles de notre approche par une série exhaustive d’expériences parallèles numériques dans un contexte académique. Cette étude exhaustive de l’extensibilité et l’efficacité parallèle de notre pré- conditionneur et de sa mise en oeuvre est réalisée sur des problèmes modèles de type équations de diffusions 3D au Chapitre 5 et déquations de convection-diffusion 3D au Chapitre 6. Pour chacun de ces modèles types, on considère différents problèmes en faisant varier la difficulté du système à résoudre. Pour les problèmes elliptiques, des situations avec de fortes discontinuités et anisotropie sont considérées. Pour les problèmes de convection-diffusion, on sintéresse en particulier à l’effet du nombre de Péclet sur la robustesse du préconditionneur. Cette étude est menée sur des machines jusquà 2048 processeurs pour résoudre des problèmes 3D à plus de 50 millions d’inconnues. Ces études ont été menées sur des machines telles que le SystemX de Virginia Tech ou l’IBM Blue-Gene du CERFACS.
Une étude sur l’influence de la sparsification a illustré le comportement du préconditionneur creux en le comparant au dense. La Figure 4.6 montre que le préconditionneur creux peut-être considérré comme robuste et efficace. Autrement dit pour des très petites valeurs du paramètre de seuil, 20% des entrées du complément du Schur sont retenues . Dans ce contexte, on observe un gain en mémoire et en calcul considérable alors que les préconditionneurs denses et creux ont des convergences très similaires (courbe en rouge). Pour des valeurs optimales du paramètre de seuil, on observe un gain énorme aussi bien en mémoire qu’en calcul (on garde moins que 5% des entrées avec un gain d’un facteur 3 en temps). Ici le préconditionneur creux nécessite quelques itérations de plus pour converger mais chaque itération est significativement plus rapide (courbe en vert). Par contre pour des valeurs très grandes du paramètre de seuil, situation oú seulement 1% des entrées du complément de Schur sont conservées, la convergence se détériore pour un gain en temps de calcul qui n’est pas très significatif. Donc un choix optimal du paramètre de seuil doit assurer un bon compromis entre le coût de construction et d’application du préconditionneur tout en assurant une bonne convergence.
0 20 40 60 80 100 120 140 160 180 200 10−16 10−14 10−12 10−10 10−8 10−6 10−4 10−2 100 # iter ||r k ||/||f|| Dense calculation Sparse with ξ=10−5 Sparse with ξ=10−4 Sparse with ξ=10−3 Sparse with ξ=10−2 0 20 40 60 80 100 10−16 10−14 10−12 10−10 10−8 10−6 10−4 10−2 100 Time(sec) ||r k ||/||f|| Dense calculation Sparse with ξ=10−5 Sparse with ξ=10−4 Sparse with ξ=10−3 Sparse with ξ=10−2
Figure 4.6: Comportement numérique de la variante creuse.
Suivant la même méthodologie, une étude sur l’effet de la précision mixte a été menée. La Figure4.7
illustre une comparaison avec les préconditionneurs mixte et double précision. On peut tout d’abord observer que le préconditionneur en précision mixte atteint le même niveau de convergence que celui en double précision sans trop pénaliser la convergence. De plus en regardant le temps de calcul, on observe un gain acceptable. On note que ce gain varie d’une plateforme à une autre. Par exemple sur des machines IBM SP4 on observe un facteur de 1.8 entre un calcul simple et double précision tandis
56
que ce facteur n’est pas observé sur une machine BlueGene sur laquelle les deux arithmétiques sont traitées à la même vitesse. On note que seul le préconditionneur est calculé en simple précision. Donc un calcul en précision mixte nous apporte un gain d’un facteur 2 au niveau de stockage ainsi qu’un gain en temps de calcul dépendant de la machine de calcul.
0 20 40 60 80 100 120 140 160 180 200 10−16 10−14 10−12 10−10 10−8 10−6 10−4 10−2 100 # iter ||rk ||/||f|| 64−bit calculation mixed arithmetic calculation
0 10 20 30 40 50 60 10−16 10−14 10−12 10−10 10−8 10−6 10−4 10−2 100 Time(sec) ||rk ||/||f|| 64−bit calculation mixed arithmetic calculation
Figure 4.7: Comportement numérique de la variante précision mixte.
Dans une seconde étape, nous nous intéressons à lévolutivité aussi d’un point de vue numérique que d’un point de vue performance parallèle des préconditionneurs. Différentes analyses peuvent être réalisées pour étudier les performances parallèles d’une approche lorsqu’on augmente le nombre de processeurs. Dans notre cas, nous avons considéré une étude de l évolutivité où l’on fait varier linéairement la taille du problème traité en fonction du nombre de processeurs utilisés (scaled scal- abilty en anglais). Pour un algorithme idéal d’un point de vue de son comportement numérique et de sa mise en oeuvre parallèle, le temps de restitution reste constant et indépendant du nombre de processeurs utilisés.
Dans ce contexte expérimental, nous illustrons dans la Figure4.8à gauche le nombre d’itérations nécessaires lorsqu’on augmente le nombre de processeurs tandis quà droite, on représente le temps de calcul nécessaire pour réaliser la simulation. Dun point de vue convergence, on peut observer que lorsqu’on augmente le nombre de processeurs de 27 à 1728, le nombre d’itérations n’augmente que de 23 à 60 ; autrement dit lorsqu’on augmente la taille du problème 64 fois le nombre d’itérations n’augmente que de 3 fois. Par contre d’un point de vue temps de calcul, on peut observer que lorsqu’on augmente la taille du problème 64 fois le temps de calcul n’est multiplié que par un facteur inférieur à 1.3 ce qui est proche de la situation idéale. En effet, la partie incompressible et commune à chacune de ses experimentations de factorisation des problèmes locaux et d’initialisation du préconditionneur constitue une part significative du calcul complet ; ceci masque partiellement l’augmentation du nombre d’itérations. Donc on peut conclure que cette méthode présente une évolutivité parallèle intéressante au niveau numérique ainsi qu’au niveau performance.
57 27 125216 343 512 729 1000 1331 1728 0 10 20 30 40 50 60 70 80 90 100 # proc # iterations
Dense 64−bit calculation Dense mixed calculation Sparse with ξ=10−4 Sparse with ξ=10−3 27 125216 343 512 729 1000 1331 1728 0 10 20 30 40 50 60 70 80 90 # proc Time(sec)
Dense 64−bit calculation Dense mixed calculation Sparse with ξ=10−4 Sparse with ξ=10−3
Chapter 5
Numerical investigations on diffusion
equations
5.1
Introduction
In this chapter, we first describe in Section5.2the computational framework and detail the academic model problems considered for our parallel numerical experiments. We investigate in Section5.3
the numerical behaviours of the sparsified and mixed arithmetic variants that are compared with the classical dense 64-bit additive Schwarz preconditioner. Section5.4is the core of the parallel study where we first illustrate through classical speedup experiments the advantage of increasing the num- ber of processors for solving a problem of a prescribed size; then we study the numerical scalability and the parallel performance of the preconditioners by conducing scaled speedup experiments where the problem size is increased linearly with the number of processors [51]. Finally we end this section by considering the effect of a two-level preconditioner.