Rapport - calmip

UTILISATEUR : Mr Olivier DUCASSE
Utilisation du supercalculateur Soleil dans le cadre de la thèse :
Modélisation électrodynamique d’un réacteur plasma hors équilibre de
dépollution des gaz
DIRECTEUR DE THESE : M. Olivier EICHWALD
RESUME DE LA THESE :
Cette thèse concerne la simulation des ondes d’ionisation (streamer) créées à la
pression atmosphérique entre une pointe et un plan dans les conditions expérimentales d’un
réacteur corona de dépollution des gaz d’échappement.
Un code informatique bidimensionnel (code 2D) a été mis au point en symétrie
cylindrique. Il résout, par la méthode des volumes finis, les équations fluides de continuité
relatives au bilan du nombre d’espèces chargées (électrons et ions), couplées à l’équation de
Poisson pour le calcul du champ électrique. La cinétique chimique prend en compte les
collisions entre espèces (ionisation, attachement, recombinaison), la photo ionisation, l’effet
photo électrique à la cathode et l’émission secondaire due au bombardement ionique. La
modélisation de la dynamique des particules chargées a été couplée à la modélisation de la
cinétique chimique des espèces radicalaires dans le but d’estimer la nature, la localisation et la
densité des radicaux formés durant la phase de décharge.
Une étude a été menée tout d’abord sur l’efficacité de plusieurs schémas numériques
d’ordre 2 pour la résolution de l’équation de continuité. Cet ouvrage a été réalisé dans les
conditions d’un test mathématique contraignant qui génère de forts gradients de densité en
mouvement dans un champ de vitesse fortement inhomogène. Ensuite, les schémas
numériques ont été appliqués à une simulation dite 1,5D de l’évolution d’un streamer. Les
performances du code 2D ont également été comparées avec un code de type éléments finis
développé à l’Université de Patras (Grèce), dans le cadre d’une collaboration inter
universitaire.
La confrontation des résultats de simulation avec ceux issus de l’expérience dans le
cas d’une décharge couronne pointe plan dans l’air et à la pression atmosphérique a
notamment conduit à l’estimation de la production des radicaux atomiques durant la phase de
décharge.
MOTS-CLES :
Dépollution par décharge couronne
Modélisation bidimensionnelle des streamers
Techniques numériques pour la résolution des équations elliptiques
Cinétique chimique
Concentrations des espèces radicalaires
Optimisation et parallélisation de code
DISCIPLINE : Physique et Ingénierie des Plasmas de décharge
LABORATOIRE : Centre de physique des Plasmas et de leur Applications de Toulouse
UMR 5002 CNRS – 118 route de Narbonne 31062 Toulouse cedex 9
Travaux réalisés dans le cadre du projet CALMIP :
Les durées de calcul nécessaires pour la première version du code étaient un élément
très pénalisant. Ainsi, la modélisation de la décharge pour un espace inter-électrode de 3mm
n’était pas envisageable (en dessous de 3mm il est très difficile d’avoir un régime stable de
streamer). En effet, la durée de calcul s’estimait à trois semaines pour que le streamer se
forme et se propage de la pointe jusqu’au plan (sans la phase de relaxation) ; la durée du
phénomène simulé était de 3ns, soit 1 semaine par nanoseconde. De plus, les courbes de
courant (expérimentales) de la décharge montraient des durées de phénomène de l’ordre de
cent nanosecondes (voir figure 5). Donc, la résolution du problème de durée de calcul
devenait primordiale. Face à cette difficulté, nous avons fait appel aux services du Centre
Interuniversitaire de Calcul de Toulouse (CICT) qui héberge le Supercalculateur « Soleil » du
groupement scientifique CALMIP (CALcul en MIdi-Pyrénées). Ainsi, nous avons diminué la
durée de calcul, à tel point que le code est maintenant capable de simuler une décharge
électrique dans un espace inter-électrode de 4mm sur une durée de 120ns, en environ 10
jours ; cette opération a demandé plus de 9 mois de travail. Ce paragraphe résume les
principales étapes de l’optimisation.
Optimisation des durées de calcul en agissant sur
l’agencement des lignes de code :
Cette première optimisation met en adéquation le code avec la manière dont le
processeur traite les informations. Cela concerne l’harmonie du complexe compilateur processeur. Par exemple, pour un calcul impliquant une matrice à deux dimensions (comme le
potentiel V(i,j)), le compilateur FORTRAN ordonne les valeurs du tableau dans la mémoire
du processeur colonne après colonne (indice j) (il fixe j et fait varier i). Dans ce cas, entre
l’indice de ligne (i) et l’indice de colonne (j), c’est l’indice de ligne qui varie le plus vite.
Ainsi, dans l’exemple de la figure 1, c’est la configuration (a) qui sera la plus rapide. Pour
quantifier le gain de temps, on mesure la durée d’un échantillon de 10000 itérations de
l’algorithme SOR (pour la résolution de l’équation de Poisson) respectivement traité dans les
configurations (a) et (b). Ce test est d’abord effectué sur le Supercalculateur Soleil du CICT.
On voit sur le tableau 1 que la succession j → i est plus rapide que celle i → j, mais la
variation est seulement de 3,7% (soit 5 secondes pour 10000 itérations). En effet, les
processeurs Itanium du Supercalculateur sont dotés d’une architecture optimisée pour le
calcul sur les nombres flottants (c'est-à-dire nombre réels) et sont donc très performant à la
base. De plus, les processeurs Itanium sont accompagnés d’un compilateur Intel spécialement
développé pour son architecture (il existe plusieurs versions de compilateur qui sont plus ou
moins performantes pour un problème donné). Cependant, on observe, toujours sur le tableau
1, qu’en utilisant l’option de compilation de niveau trois, on diminue la durée de calcul des
10000 itérations de SOR de 39% par rapport à la configuration initiale (l’augmentation de
l’ordre des options de compilation conduit à des exécutables de taille mémoire plus
importante mais optimisés pour le calcul). Le même test effectué sur le PC Xéon du groupe
avec un compilateur FORTRAN GNU réduit la durée de calcul d’un facteur 2 (diminution de
50% au lieu de 3,7%).
Pour j = 0 → nz
Pour i = 0→ nr
V(i,j)=A
Pour i = 0 → nr
Pour j = 0→ nz
V(i,j)=A
(b)
(a)
Figure 1 : Présentation de deux manières d’effectuer un calcul au sein d’une matrice. Le résultat
numérique est identique dans les deux cas mais les durées de calcul sont très différentes (cf. tableau 1).
Configuration
Boucles imbriquées i puis j
Boucles imbriquées j puis i
Boucles imbriquées i puis j avec option de
compilation de niveau 3
Boucles imbriquées j puis i avec option de
compilation de niveau 3
Durée (s)
135
130 (-3,7%)
108 (-20%)
82
(-39%)
Tableau 1 : Mise en évidence de l’ordre des boucles imbriquées, avec et sans option de compilation, sur la
consommation en temps. Mesures réalisées avec un processeur Itanuim II 1,5GHz et sur un échantillon de
10000 itérations de l’algorithme SOR.
Un autre phénomène sur lequel on joue, grâce à l’agencement des lignes de code, est
l’effet « pipeline ». Il s’agit, pour le système, d’utiliser au maximum ses ressources et de faire
en sorte qu’il n’y ai pas de temps mort au cours de chaque cycle du processeur (dans le
meilleur des cas, un cycle = un calcul et les calculs s’effectuent à la vitesse d’horloge du
calculateur qui fonctionne à X cycles par seconde). Par exemple, le déroulement des boucles
sur deux voir trois niveaux alimente le « pipeline » et améliore en conséquence la durée de
calcul. Ainsi, le déroulement sur deux niveaux (cf. figure 2), de la boucle initiale décrite sur la
figure 1a, diminue la durée de calcul de 42% et de 58% lorsque le déroulement est étendu à
deux puis trois niveaux (voir le tableau 2). Dans ce cas, les ressources du système sont
utilisées au mieux ce que l’on constate en observant sur le tableau 2 l’augmentation du flux
d’opérations (flop/s = floating operations per second).
Pour j = 0 → nz
Pour i = 0 → nr par pas de 2
V(i,j)=A
V(i+1,j)=A
Figure 2 : Présentation du déroulement (unrolling) sur deux niveaux de la boucle associée à la variable i.
Déroulement sur X niveaux
1
2
3
Durée pour 10000 itérations
(s)
82,6
48,0 (-42%)
34,9 (-58%)
Tableau 2 : Mise en évidence du déroulement des boucles sur le pipeline.
Flux d’opérations (Mflop/s)
1217
2037
2707
Parallélisation du code :
La parallélisation du code est la solution qui, après les premiers travaux d’optimisation
présentés ci-dessus, pousse davantage les performances en terme de consommation en temps.
Cependant, c’est un procédé qui a aussi ses limites. Le principe de la parallélisation est très
simple à comprendre ne serait-ce que par son nom évocateur. Il s’agit de répartir sur plusieurs
processeurs, le coût total normalement supporté par un seul. C’est ainsi que la vitesse de
calcul pourrait diminuer d’un facteur correspondant au nombre de processeurs mis en jeu.
Cependant, la loi de Amdahl limite cette tendance et montre qu’en pratique un code
parallélisé à 90% de son volume ne peut dépasser un accroissement de la vitesse d’un facteur
supérieur à 10.
Le projet de la thèse étant la construction d’un code pour la modélisation du
phénomène de décharge de type streamer et non pas la parallélisation du code, on a opté pour
une parallélisation simple à mettre en œuvre (donc peu coûteuse en temps d’investissement).
La parallélisation choisie qui respecte ce cahier des charges, tire partie de l’aspect Mémoire
Partagée du Supercalculateur Soleil hébergé au CICT. La mise en œuvre de la parallèlisation
s’est appuyée sur le procédé OpenMP (Mémoire Partagée). C’est un procédé très efficace à
moindre coût (en terme de modification du code). A l’origine, l’algorithme SOR n’est pas
conçu pour la parallélisation ; on a donc adopté, pour appliquer le procédé de parallélisation,
le schéma dit red and black [Pr-1] qui traite de manière indépendante le calcul du potentiel
d’un demi domaine à l’autre ; le domaine est découpé en un damier similaire à celui d’un jeu
d’échec.
Les résultats de la figure 3 illustrent les variations du gain en temps (obtenu grâce à la
parallélisation) en fonction du nombre de processeurs. Il s’agit de la durée totale consommée
pour effectuer 7000 pas de temps avec option de compilation de niveau trois et l’ensemble des
optimisations décrites dans les paragraphes précédents. On constate que la consommation en
monoprocesseur (on parle aussi de séquentiel) est de 9h42’ à 99%CPU, avec deux
processeurs, 2h46’ à 189%CPU et avec quatre processeurs 3h42’ à 306%CPU. Cet exemple
illustre bien le fait qu’on ne peut pas diminuer la durée de calcul par le simple fait
d’augmenter le nombre de processeurs. En effet, on note pour 4 processeurs, qu’il y a
quasiment 1 processeur qui ne travaille pas (306%CPU). Comme ce dernier coûte plus qu’il
ne rapporte, la durée globale augmente et cette configuration est donc à bannir.
On note aussi que le gain en temps, entre le fonctionnement séquentiel et biprocesseur
du code, est voisin d’un facteur 5. Cette valeur est en contradiction avec la règle, puisque le
facteur de gain en temps ne peut pas excéder le nombre de processeurs. Ce type d’accélération
sur-linéaire est souvent lié à des effets de mémoire cache. En effet, dans notre cas, la
consommation mémoire du problème est divisée en deux (biprocesseurs) ; ainsi chaque sous
problème a plus de chance de résider dans des zones mémoires à accès rapide (comme le
niveau de cache L1).
12
durée (h)
10
8
6
4
2
1
2
3
4
nombre de processeurs
Figure 3 : Influence du nombre de processeurs sur la durée de calcul pour 7000 itérations temporelles et
l’option de compilation de niveau 3. Le graphique montre que la décroissance de la durée de calcul n’est
pas forcément assurée par le simple fait d’augmenter le nombre de processeurs.
Au bilan, on réalise une estimation du gain en temps obtenu entre la première version
du code qui fonctionnait en monoprocesseur (Xeon 3,4GHz), sans optimisation, et la dernière
qui fonctionne en biprocesseur (Itanium II 1,5GHz). Le test est réalisé sur un échantillon de
1000 itérations temporelles pour la configuration pointe-plan avec un rayon de courbure de
20µm et une distance inter-électrode de 4mm. De plus, le nombre total de points de
discrétisation de l’espace géométrique est proche de 200000. Ainsi, la première version du
code consomme 31h26’ (1886min) à 99% CPU alors que la dernière ne consomme que 20min
à 183% CPU. Ainsi, au bout de neuf mois de travail, la durée de calcul a été diminuée de
98,9%.
La parallélisation du code sera poursuivit, toujours en collaboration avec le CICT, en
implantant le mode « par transfert de message » à l’aide de la librairie MPI (Message Passing
Interface). C’est une méthode plus lourde à mettre en œuvre et qui demande un réel savoir
faire, mais qui à terme donnera de meilleurs résultats par rapport à ceux obtenus avec
openMP.
[Pr-1]
[Du-1]
W. H. Press, S. A. Teukolsky, W. T. Vetterling, B. P. Flannery, « Numerical recipes in fortran
; the art of scientific computing », Cambridge university press, second edition.
O Ducasse, L Papageorghiou, O Eichwald, N Spyrou, M Yousfi, « Comparison of two model
with FVM and FEM : critical analysis », to be pubished, (2007).
Exemples de résultats issus du code 2D optimisé :
Figure 4 : Evolution du champ électrique en Townsend (Td) dans le plan de coupe (Orz). Instants : 20, 30,
45, 60, 90 et 130 ns.
140
130
données expérimentales
données du modèle x 10
120
110
intensite (mA)
100
90
80
70
60
50
40
30
20
10
0
0
10
20
30
40
50
60
70
80
90
100
110
temps (ns)
Figure 5 : Comparaison des formes de courant expérimentale et simulée sur 120ns.
120