« Paleo-climate » simulation of Hot Jupiters

By adapting the 3D general circulation model DYNAMICO developed at LSCE to the study of exoplanets, the ERC-ATMO team has shown that the unexplained radius inflation of Hot Jupiters is the result of the long timescale meridional circulations that heat up the deep atmosphere. Thanks to the increased performances of the code and by using low resolutions (similarly to paleo-climate studies for Earth climate), simulations on a timescale of 1000 years  (usual runs in the literature used a timescale of ~1 year) demonstrate that the deep circulations induced by the irradiation in the outer atmosphere are sufficient to confine the heat in the interior of the planet and keep it "puffy". The full article detailing these simulations, and our analysis of the results, is available online as part of Issue 632 (December 2019) of Astronomy and Astrophysics.

Averaged temperature profile of the simulation showing the heating of the deep atmosphere on a time scale of 1000 years.

Stream function of the simulation: clockwise circulations on the meridional plane are shown in red and anticlockwise circulations are shown in blue. Additionally the zonally and temporally averaged zonal wind is plotted in black (solid = eastward, dashed = westward).

InKS, un modèle de programmation pour la séparation de l’algorithme et des optimisations dans les codes HPC

Dans le cadre de sa thèse à la Maison de la Simulation sous la direction de M. Mehrenberger et M. Bastoul et sous l'encadrement de Julien Bigot (Maison de la Simulation) et Olivier Aumage (INRIA), Ksander EJJAAOUANI a développé un nouveau modèle de programmation du nom de InKS.

Le modèle de programmation InKS vise à améliorer la lisibilité, la portabilité et la maintenabilité des codes de simulation tout en accroissant la productivité des développeurs de telles applications. Pour atteindre ces objectifs, InKS propose deux langages, chacun dédié à une partie de l’application. Le premier, InKSPIA, permet d’exprimer les aspects algorithmiques d’un code de simulation scientifique tout en laissant les choix d’optimisation de côté. Il s’agit de décrire les fondations de la simulation : son algorithme. Le second langage, InKSPSO, permet aux spécialistes de l’optimisation de réutiliser les informations contenues dans l’algorithme pour exprimer une large variété de choix d’optimisation.  Le modèle permet d’écrire de nombreuses versions des optimisations, typiquement une par architecture, à partir d’un unique algorithme. En basant les différentes versions d’un programme sur sa partie invariante, l’algorithme, le modèle InKS limite la réécriture du code, boostant la productivité des développeurs. Son fonctionnement est simplifié dans le schéma ci-dessous.

Présentation du modèle de programmation InKS

Suite à la proposition du modèle InKS et de son implémentation, nous avons évalué le modèle au travers de l'implémentation de simulations de plasma: le système Vlasov-Poisson 6D. Cette évaluation a permis de mettre en évidence certaines bonnes propriétés du modèle, notamment en matière de séparation des aspects, mais aussi à montrer sa généralité et ses performances. Pour ce faire, nous avons comparé l'efficacité de deux implémentations du système Vlasov-Poisson 6D, écrite sur InKS ou Fortran. Pour les optimisations les plus importantes, le nombre de lignes dans les deux cas est similaire. Cependant, la présence de l'algorithme permet d'ordonnancer automatiquement, en une simple ligne, un large ensemble de calcul, verbeux et potentiellement sujet aux erreurs. Ainsi, dans les parties non critiques du code, InKSPSO peut résumer une partie du programme de manière concise, permettant de se concentrer sur les parties de calcul intensif. Par ailleurs, en limitant la réécriture du code aux seules optimisations, InKS permet de tester plusieurs stratégies d'optimisations afin d'identifier la plus adaptée à une architecture donnée. En comparaison, dans ces situations, les applications traditionnelles requièrent la réécriture d'une plus grande partie du code, limitant le temps consacré à la recherche des meilleures stratégies d'optimisation.

Les résultats obtenus avec InKS ont fait l'objet de plusieurs publications:

Le projet est par ailleurs hébergé librement sur GitHub.

Ksander EJJAAOUANI présentera ses travaux de thèses le 25 octobre prochain et notamment ses développements au sein de InkS.

Optimisation SIMD du code Smilei

L'importance de la vectorisation

Les processeurs Intel de dernière génération utilise la vectorisation dite SIMD pour Single Instruction Multiple Data. Cette technologie présente dans chaque cœur de calcul permet d'effectuer pour le même coût qu'une instruction scalaire une addition et une multiplication sur un vecteur de données allant jusqu’à 8 flottants double précision. On comprend dès lors qu'un facteur d'accélération important peut être perdu sans la vectorisation. Pour les codes fonctionnant sur CPU Intel et souhaitant atteindre les meilleures performances par cœur, être capable d'utiliser la vectorisation est essentiel. Hors sur de nombreux algorithmes, le passage du scalaire au vectoriel peut s'avérer inefficace voir tout simplement impossible en l'état (le compilateur atteignant ses limites). Il est alors nécessaire pour les développeurs de retravailler les algorithmes pour bénéficier de la vectorisation. Cela passe le plus souvent par une réécriture afin d'éviter les problèmes de mise en cache, les accès mémoires aléatoires et les concurrences d'accès.

Description de la notion de vectorisation SIMD. FMA signifie Fused Multiply Add et correspond à l'instruction qui assimile une multiplication et une addition à la fois.

L'optimisation du code Smilei

Les équipes de la Maison de la Simulation ont travaillé sur l'optimisation SIMD du code de simulation Smilei en collaboration avec les équipes scientifiques du LLR et du LULI. Le code Smilei est un code Particle-In-Cell open-source collaboratif massivement parallèle dédié principalement à la simulation de l'interaction laser-plasma mais il est aussi utilisé en astrophysique de laboratoire et en fusion.

L’optimisation du code s'est achevée dans le cadre du grand challenge Irene Joliot-Curie. Pour rappel, les grands challenges donnent accès aux machines de calcul avant leur ouverture officiel dans le but de tester le bon fonctionnement du matériel et des logiciels. Il nous a permis de tester les nouveaux opérateurs vectoriels sur des cas de production en utilisant plusieurs dizaines de millier de cœur Skylake.

Nous avons également développé une méthode de vectorisation adaptative en espace et en temps permettant de déterminer localement le plus efficace entre avoir un opérateur scalaire ou vectoriel. En effet, nous avons découvert que les opérateurs vectoriels n'avaient pas d’intérêt pour une charge faible en particules par patch, le patch étant le plus petit grain de décomposition de la grille (différence finie) en espace. Pour peu de particules, les anciens opérateurs restent les plus rapides. Cela vient du fait que la vectorisation nécessite une certaine quantité d’éléments (ici, les particules) à traiter pour être très efficace.

Ces résultats ont été publiés dans Computer Physics Communication et sont accessible en ligne sur ce lien. La vidéo ci-dessous illustre l'utilisation de la vectorisation adaptative sur de larges cas. Les simulations ont été réalisées sur le calculateur Irene Joliot-Curie.

Article publié dans Computer Physics Communication.