Dans le but de r´ealiser un calcul r´ealiste des ceintures de radiation, le code HELIOS est pass´e d’un code d’´etude `a un code de production, ce qui signifie qu’il a ´et´e adapt´e au centre de calcul du CEA, de mani`ere `a pouvoir r´ealiser des calculs coˆuteux et rester longtemps en machine.
Stockage hi´erarchique et partag´e (SHERPA)
Sur le centre de Bruy`eres-Le-Chˆatel, l’augmentation du volume de donn´ees scienti- fiques (jusqu’`a 1To pour un cas) et des besoins de d´ebits (environs 100Mo/s par fichier), a n´ecessit´e la s´eparation des fonctionnalit´es de calculateur et de serveur de fichiers (pro- jet SHERPA : Stockage HiERarchique et PArtag´e). La nouvelle architecture du centre de calcul (depuis 1997) permet la migration et la sauvegarde des fichiers pr´esents sur les calculateurs et en particulier sur le super-calculateur TERA 10 depuis 2006 (cf fi- gure 7.5).
Afin de disposer des meilleures performances de lectures/´ecritures de fichiers, il existe sur le supercalculateur un syst`eme de cache. Ce cache est constitu´e d’un espace disque local aux calculateurs et d’une interface logicielle permettant de maintenir la coh´erence entre ce cache et le serveur de stockage HPSS (High Performance Storage System). Toutes les lectures/´ecritures de fichiers sont donc faites localement au calculateur, puis les fichiers sont copi´es sur le serveur de stockage. Celui-ci g`ere des disques et des bandes capables de maintenir un tr`es gros volume de donn´ees. Pour des raisons de perfor- mance, les lectures/´ecritures des fichiers ne peuvent se faire directement sur le serveur de stockage en raison d’un temps de latence, fonction de la disponibilit´e des bandes, qui s’ajoute au temps d’´ecriture.
II. Travail d’optimisation du code HELIOS sur le supercalculateur TERA 10 145
Le syst`eme de fichiers, local au calculateur, est nomm´e /cache-prot (cache des protections - cf paragraphe suivant). Il y en a un par calculateur, ou serveur connect´e au serveur de stockage. Le syst`eme de fichiers HPSS du serveur de stockage est nomm´e /prot (protections). Il est unique sur le centre de calcul.
Fig. 7.5 – Sch´ema simplifi´e de l’architecture du centre de calcul de Bruy`eres-le-Chˆatel.
Gestion des protections-reprises
Compte tenu du grand nombre continu d’utilisateurs du super-calculateur, le passage des calculs en machine sont g´er´es par un serveur qui d´efinit un ordre de passage en fonction des priorit´es des calculs. Ces priorit´es sont d´efinies par un certain nombre de crit`eres : le nombre de processeurs demand´es, la disponibilit´e des processeurs, la dur´ee de calcul demand´ee par l’utilisateur... Les passages en machine ne durent pas plus de huit heures. Ainsi, pour les calculs qui ne sont pas termin´es `a la fin d’un passage en machine, il est n´ecessaire de mettre en place un syst`eme de protections-reprises des calculs. Ce syst`eme consiste `a ajouter dans le code de calcul une ”protection” permettant de bien sauvegarder toutes les donn´ees n´ecessaires `a un passage suppl´ementaire en machine et une ”reprise” qui permet la relecture des donn´ees stock´ees et le red´emarage des calculs `a l’endroit o`u ils se sont arrˆet´es. Une fois ce syst`eme mis en place, l’utilisateur peut demander le nombre de passages qu’il d´esire ; ainsi, tant que ce nombre n’est pas atteint, `a la fin d’un passage, le calcul est remis automatiquement dans la file d’attente de la machine pour un passage suppl´ementaire.
Les fichiers de reprises doivent ˆetre sauvegard´es sur le /prot afin de ne pas ˆetre perdus. Il est n´ecessaire de coupler le syst`eme de ”protections-reprises” aux instructions de communications entre le serveur de calcul et le serveur de stockage. Les fichiers de reprise sont ´ecrits sur le /cache-prot, copi´es sur le /prot, puis relus sur le /cache-prot.
146 Chapitre 7. Optimisation et parall´elisme
III
R´esultats : gains en performance obtenus avec
le code parall`ele optimis´e
La figure 7.6 montre les performances du code optimis´e : la r´eduction du temps de calcul et le speed-up obtenu.
Sur le premier graphe (a), on peut observer que l’optimisation a permis, en moyenne, la r´eduction d’un facteur 3.7 du temps d’ex´ecution du calcul `a 108 degr´es de libert´e par
pas de temps (courbe rouge). Pour des calculs plus petits, `a 5.12 106 degr´es de libert´e
par pas de temps (courbe bleue), le taux de r´eduction du temps de calcul est plus important : de 6.2 en s´equentiel, 6.8 sur 5 processeurs, ou encore 5.2 sur 10 processeurs. En effet, les nombreuses boucles du code de calcul ont ´et´e vectoris´ees de fa¸con optimale par le compilateur grˆace aux instructions de type #pragma ivdep. Le code est alors tr`es efficace pour un petit nombre de processeurs quand la charge de calculs est relativement faible. Dans ce cas, l’augmentation du nombre de processeurs r´eduit l’efficacit´e du code : la charge de calculs par processeur est trop faible et les communications, qui sont de plus en plus nombreuses quand le nombre de processeurs augmente, ralentissent les calculs.
La grande efficacit´e du code optimis´e pour des calculs relativement petits est ´egalement illustr´ee sur le graphe (b) de la figure 7.6. On peut voir en effet que les speed-up obtenus avec le nouveau code sont plus petits qu’avant l’optimisation pour N = 40 et I = 80 (courbe bleue) : le meilleur speed-up est de 3.7 au lieu de 6 dans le cas non optimis´e (cf figure 7.3). Ceci est dˆu au fait que le temps s´equentiel est beaucoup plus petit qu’avec le code non-optimis´e : 16.5 secondes au lieu de 105 secondes. On remarque que ce temps s´equentiel de 16.5 secondes correspond au mˆeme ordre de grandeur que le temps de calcul obtenu avec le code non-optimis´e sur 40 processeurs (17.4 secondes). Dans le cas d’un calcul plus coˆuteux, N = 100 et I = 100 (courbe rouge), les speed-up sont meilleurs que ceux obtenus pr´ec´edement avec le code non-optimis´e : la valeur optimale, obtenue avec 100 processeurs, est de 18 au lieu de 17.2 avant l’optimisation.
Une nouvelle analyse de profile du code HELIOS optimis´e (cf figure 7.7) montre qu’une grande partie du temps CPU (environ 45% dans le cas N = 40, I = 100) est pass´e dans la routine RKA-parallele1. En effet, cette routine est la seule contenant des
communications MPI. De plus, d’apr`es l’ordre dans lequel le tableau solution F est rang´e, la routine D1, appel´ee quatre fois dans RKA-parallele1, ne permet pas une bonne vecto-
risation et n´ecessite des “sauts en m´emoire” (stride) de taille [(N + 1)/Np]3.
Les r´eductions importantes des temps de calcul, apport´ees par le code HELIOS optimis´e, ont permis de r´ealiser des calculs physiques d’instabilit´es Weibel et whistlers `a une et deux esp`eces d’´electrons. Ces calculs sont pr´esent´es au chapitre suivant.
III. R´esultats : gains en performance obtenus avec le code parall`ele optimis´e 147 0 20 40 60 80 100 3 3.5 4 4.5 5 5.5 6 6.5 7 Nombre de processeurs
Temps du code optimisé / Temps du code non optimisé
N=40,I=80 N=100,I=100 (a) 0 20 40 60 80 100 0 2 4 6 8 10 12 14 16 18 Nombre de processeurs Speed−up N=40,I=80 N=100,I=100 (b)
Fig. 7.6 – Taux de r´eduction des temps de calcul grˆace au travail d’optimisation r´ealis´e sur le code HELIOS et speed-up du code optimis´e.
148 Chapitre 7. Optimisation et parall´elisme
Fig. 7.7 – Etude de coˆuts, en temps CPU, des routines du code HELIOS optimis´e (pro- file) sur une it´eration, avec le logiciel ”gprof”. Les param`etres de la simulation sont :N+1 =40, I=100 et Np = 20.
149
Chapitre 8
R´esultats 1Dx-3Dv
Dans ce chapitre, nous pr´esentons les calculs de validation du code HELIOS 1Dx-3Dv. Nous cherchons `a reproduire le d´eveloppement lin´eaire et la saturation non-lin´eaire des ondes pour des instabilit´es de type Weibel dans le cas de plasmas sans champ magn´etique statique et pour des instabilit´es de type whistler dans le cas de plasmas anisotropes. Dans un premier temps, ces calculs sont r´ealis´es pour des plasmas ne contenant qu’une esp`ece d’´electrons non-relativistes. Puis nous ´etudions une instabilit´e Weibel dans un plasma `a deux esp`eces d’´electrons relativistes. Enfin nous r´ealisons un premier calcul d’instabilit´e whistler dans les ceintures de Van Allen, au niveau de l’orbite g´eostationnaire. Les simulations sont r´ealis´ees avec le code HELIOS parall´elis´e et optimis´e. Nous comparons les valeurs de taux de croissance obtenues num´eriquement, avec les valeurs pr´edites par la th´eorie lin´eaire. Une partie des r´esultats est ´egalement compar´ee `a des r´esultats PIC, obtenus avec le code CALDER d´evelopp´e au D´epartement de Physique Th´eorique et Appliqu´ee du CEA [82]. Ces r´esultats ont ´et´e fournis par Laurent Gr´emillet1. On rappelle
que dans la version actuelle du code, les conditions aux bords du domaine spatial sont p´eriodiques.
I
Cas tests classiques avec une esp`ece d’´electrons
Dans ces premiers cas tests, le plasma est non-relativiste et ne contient qu’une seule esp`ece d’´electrons. Les ions sont consid´er´es comme immobiles et assurent la neutralit´e ´electrique globale du syst`eme.