Page 1 SIESTE février 2005 Un coupleur dynamique de codes parallèles URL: Thierry Morel

Page 2 Le problème du couplage Pourquoi coupler des codes de calcul ? -Traiter un système dans sa globalité (océan atmosphère, fluides structure, …). -Tirer partie des avantages des codes existants pour améliorer la modélisation. Coupler des codes de calcul existants ça veut dire : -Lancer leur exécution -Échanger des informations tout au long de leur exécution -Synchroniser les calculs Prog1 Prog2 données

Page 3 Comment procéder ? Première solution : fusion des deux codes de calcul Prog1 & prog2 Program prog2 Subroutine sub_prog2(in,out) … end Program prog1 … Call sub_prog2(in, out) … end Très efficace en CPU MAIS: Problèmes d’intégration : common, unités logiques, options de compil… Maintenance ??? Modularité ? Langages différents ? Mémoire, calcul parallèle ?

Page 4 Comment procéder ? Seconde solution : utiliser une librairie de communication (PVM, MPI, …) Prog1 Prog2 Program prog2 … Call XXX_recv(données) end Program prog1 … Call XXX_send(données) end Efficace Mais couplage au cas par cas Pas réutilisable Compliqué avec plus de deux codes et de nombreux échanges

Page 5 Utilisation d’un coupleur Troisième solution : utiliser un coupleur ! Prog1 Prog2 C’est le coupleur qui lance des exécutables indépendant en parallèle Quand on veut échanger des données on appelle des primitives PUT/GET « end point» Les communications effectives sont décrites dans la namecouple d’OASIS ou dans l’IHM PALM Derrière ces primitives le coupleur utilise une librairie de communication (fichiers, pipe, PVM, MPI…) Dans OASIS, on met l’accent sur l’interpolation spatiale des champs géophysiques (grilles différentes entre les modèles) Gain énorme sur l’intégration, la maintenance, la modularité, l’interpolation, les calculs sur les données échangées, la standardisation des échanges, … PALM OASIS

Page 6 Et PALM ? Le mécanisme de couplage apporte de la souplesse, pourquoi ne pas le généraliser aux applications complexes ? Assimilation de données : des formules compliquées : Minimiser J = || x – x b || P -1 + ||H(x)-y 0 || R -1 Des tas de méthodes, plus ou moins complexes, coûteuse, appropriées … 3DFGAT : grad  x J(  x) = B -1  x +  H i T R i -1 (H i  x + d i ) 4DVAR : grad  x 0 J(  x 0 ) = B -1  x 0 +  M i,0 T H i T R i -1 (H i (M i,0 (x 0 +  x 0 )) - y 0 i ) Mais avec des opérateurs communs Avec PALM ou découpe (découple !) l’application pour ensuite l’assembler dans une interface graphique pour faciliter l’intégration. Chaque opérateur devient un programme indépendant de l’application. Mais on a besoin d’enchaîner les calculs pour reconstruire l’algorithme (ou les algorithmes), boucles, conditions … Pour cela on utilise une interface graphique Pre_PALM qui autorise les structures de contrôles autour du lancement des unités. PALM est un coupleur dynamique

Page 7 DEUX PALM PALM_RESEARCH Première version du Coupleur SPMP émulant du MPMD (pour des raisons techniques MPI) C’est fait, ça marche, c’est utilisé. N’évolue plus depuis 2001 PALM_MP Version définitive, optimisée et maintenue Vrai MPMD Plus de fonctionnalités

Page 8 Piqûre de rappel : le vocabulaire PALM Unité : composant informatique (subroutine fortran, fonction C, C++) qui consomme et produit des données Objet : quantité de donnée produite ou consommée par une unité (put/get dans le code) Branche : séquence d’unités et d’instructions Communication : échange d’un objet entre deux unités

Page 9 PALM_MP OPTIMISATION de la MEMOIRE Prog 1 Prog 2 PALM Prog 1 Prog 2 PALM Prog 1 Prog 2 PALM Prog 1 Prog 2 PALM PALM_RESEARCH : mpirun –np 3 appli PALM_MP : mpirun –np 1 PALM Mémoire statique Mémoire dynamique buffer Mémoire totale sur chaque processeur Proc 0 Proc 1 Proc 2 Mémoire statique Mémoire dynamique buffer Mémoire totale sur chaque processeur Proc 0 Proc 1 Proc 2

Page 10 PALM_MP OPTIMISATION du process management Si le nombre de processeurs est insuffisant pour faire tourner toutes les branches en //, les unités deviennent concurrentes, elles sont lancées en fonction de leur priorité Les blocs permettent de regrouper plusieurs unités en un seul exécutable pour partager de la mémoire (comme pour PALM_research) ou pour optimiser le lancement des unités

Page 11 PALM_MP Plus de souplesse pour les COMMUNICATIONS Les variables du code de branche peuvent être données directement à un PALM_Get On peut même remplir un vecteur à la volée avec une expression f90, l’expression peut faire intervenir les constantes et les variables de la branche

Page 12 PALM_MP Plus de souplesse pour les COMMUNICATIONS Les sous objets permettent de ne récupérer qu’une partie d’un objet, ou de le composer par différents objets sans intervention dans les unités Héritage des espaces pour les communications

Page 13 PALM_MP Plus de souplesse pour les COMMUNICATIONS // distribution Les distributions et les localisations sont déclarée au niveau des OBJETS dans les cartes d’identités ! PALM_LOCALISATION -name ma_loc\ ! -type replicated \ ! -description {1:3:1;5} !PALM_OBJECT -name nom_de_l_objet\ !-space nom_de_l_espace\ ! -distributor nom_du_distributeur\ ! -localisation nom_de_la_localisation\ !-tag ON/OFF\ !-time ON/OFF\ !-intent IN/OUT/INOUT\ localisation association au niveau de la communication (en général elle est automatique) objet !PALM_DISTRIBUTOR -name nom_du_distributeur\ ! -type regular/custom/regular_wh \ ! -shape shape_de_l_objet_concerne\ ! -nbproc nombre_de_proc_du_distributeur \ ! -function nom_de_la_fonction_de_distribution\ ! -comment {commentaire du distributeur}

Page 14 PALM_MP Algèbre mono ou parallèle Cartes d’identités identiques pour les unités d’algèbre et les unités utilisateur

Page 15 PALM_MP Regroupement d’unités Creation d’une nouvelle id_card Communications internes

Page 16 PALM_MP Monitorage temps réel

Page 17 PALM_MP Pour bientôt Les objets mono de taille dynamique Pour après Définition dynamique des distributions Les I/O parallèles