Thierry Morel, morel@cerfacs.fr Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry.

Thierry Morel, morel@cerfacs.fr
Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry Morel,

Plan de la présentation
Le problème du couplage de code Les solutions avec OpenPALM L’instrumentation d’un code Quelques applications OpenPALM

Pourquoi coupler ? Pour traiter un système dans sa globalité
Pourquoi coupler des codes ? Pour traiter un système dans sa globalité changement climatique : couplage océan, atmosphère, glace de mer, sol Interaction fluide structure, etc. Plusieurs codes pour traiter des physiques différentes ayant des interactions. Changement climatique Cycle de l’a zote : projet ANR ESCAPADE

Pourquoi coupler ? Mais aussi : Construire des applications autour d’un code de calcul Boucle d’optimisation Post-processing parallèle, Simulations d’ensembles …

océanographie opérationnelle
Pourquoi coupler ? Ou encore : Construire des applications parallèles modulaires à base de composants élémentaires assimilation de données Mercator Océan océanographie opérationnelle Eclatement du code en composants élémentaires pour mieux les assembler avec des algorithmes différents en tirant partie du parallélisme.

Comment s’y prendre ? Première solution : fusion des deux codes de calcul prog1 & prog2 Program prog1 … Call sub_prog2(in, out) end Program prog2 Subroutine sub_prog2(in,out) … end Très efficace en temps de calcul (passage des données par adresse, …) Problèmes d’intégration (pas d’indépendance informatique des codes): common, unités logiques, options de compilation, langages, … Degré zéro de la flexibilité (problèmes de maintenance, évolution, …) Problèmes éventuels de mémoire Pas d’indépendance de parallélisme C’est de l’assemblage et non du couplage (pas de parallélisme)

Comment s’y prendre ? Seconde solution : utiliser une protocole de communication (PVM, MPI, CORBA, pipe UNIX, fichiers, SOCKET …) Prog1 send recv Prog2 recv send Program prog1 … Call XXX_send(prog2, données) end Program prog2 … Call XXX_recv(prog1, données) end Plus ou moins efficace selon le mécanisme Couplage non générique : l’instrumentation du code dépend de l’application Demande une bonne expertise en calcul parallèle Couplage non flexible (parallélisme, interpolation, …) Pas toujours portable selon le mécanisme utilisé Trop complexe avec plus de deux codes et de nombreux échanges

Comment s’y prendre ? SALOME Troisième solution : utiliser un coupleur
MPCCI OASIS OpenPALM Prog1 Prog2 Pas de problèmes d’intégration et de mémoire : les codes restent indépendants Flexibilité (problèmes de maintenance, évolution, …) Indépendance du parallélisme L’efficacité dépend du couplage et du coupleur Le coupleur propose des outils qu’on n’aura pas à développer, interpolation, redistribution des données Si l’un des codes a déjà été instrumenté avec ce coupleur, une partie du travail peut être récupérée Demande un investissement non négligeable au départ

Les caractéristiques du coupleur PALM
Coupleurs classiques Coupleur PALM Couplage statique Couplage dynamique Code1 Code2 condition Code1 Boucle temps Code3 Code4 Code2 Les deux codes de calcul sont lancés en début de simulation et se terminent ensemble à la fin de l’application Exemple : couplage Océan/Atmosphère pour le climat Lancement en boucle ou sous condition Description d’algorithmes complexes Gestion dynamique des ressources (processeurs et mémoire)

Unité : composant informatique -Code de calcul -Partie d’un code de calcul -Unité prédéfinie de la boite à outils - subroutine fortran, fonction C ou C++ - script Python, tcl, Octave, R, … - programme indépendant Unités : composants à coupler (éventuellement parallèle) Objets : variables de couplage (mais pas que les champs) Branche : c’est l’algorithme du schéma de couplage Communication : l’échange de données Nombre de proc Unité parallèle 32

Branche : séquence d’unités, d’instructions et de structures de contrôle : algorithme Unités : composants à coupler (éventuellement parallèle) Objets : variables de couplage (mais pas que les champs) Branche : c’est l’algorithme du schéma de couplage Communication : l’échange de données

Deux niveaux de parallélisme pour exploiter au maximum le parallélisme intrinsèque d’une application Parallélisme de tâches : branches Calcul parallèle « en dessinant » On donne les moyens à l’utilisateur d’exploiter au maximum le parallélisme. Les 2 niveaux … Ce parallélisme est flexible … Composants distribués : unités Assemblage de composants : blocs

Objet : quantité de données produite ou consommée par une unité Communication : échange d’un objet entre deux unités Les communications effectives sont décrites en reliant les plots dans l’interface graphique PrePALM Unités : composants à coupler (éventuellement parallèle) Objets : variables de couplage (mais pas que les champs) Branche : c’est l’algorithme du schéma de couplage Communication : l’échange de données

Schéma de communication « end point »  Pas de spécification concernant l’unité réceptrice ou émettrice de l’objet produit ou consommé dans les codes de calcul Dans le code source des unités : envoi ou réception potentiel Production de données : SERVEUR CALL PALM_Put (…) Consommation de données : CLIENT CALL PALM_Get (…) Indépendance au niveau de l’échange des données On gère cette indépendance grâce à un schéma de communication end-point.

Instrumentation du code source CALL PALM_Put (‘space1’, ‘obj1’, time, tag , array, error) CALL PALM_Get (‘space2’, ‘obj2’, time, tag , array, error) Chaîne de caractère contenant le nom de l’espace associé à l’objet Chaîne de caractère contenant le nom de l’objet Entier qui indique le time associé à cette instance de l’objet Entier qui indique le tag associé à cette instance de l’objet Variable contenant les données associées à l’objet Code d’erreur Instrumentation dans tout le code Put non bloquants Utilisation du code d’erreur

PALM_Put Le PALM_Put n’est jamais bloquant pour répondre à ceci : indépendance totale des codes à coupler, ce qui impose que l’ordre de mise à disposition des champs de couplage est quelconque on libère le code de calcul le plus tôt possible, une fois les données produites pour qu’il puisse continuer ses calculs on veut pouvoir envoyer de l’information entre deux processus qui ne tournent pas forcément en même temps, exemple du chaînage de code un même PALM_Put peut avoir plusieurs destinataires Que se passe t’il derrière un appel à PALM_Put ? rien si aucune communication n’est décrite un envoi direct MPI si le récepteur est déjà en attente de données un stockage dans une mémoire temporaire (driver de PALM) si le récepteur n’est pas encore là pour recevoir le message un stockage explicite vers une mémoire permanente si l’utilisateur l’a demandé. au choix de l’utilisateur, une écriture dans un fichier NETCDF

PALM_Get Que se passe t’il derrière un appel à PALM_Get ? rien si aucune communication n’est décrite, mais code d’erreur retourné une attente puis un Recv MPI si la donnée n’est pas encore produite. une récupération dans une mémoire temporaire ou permanente si la donnée y est stockée l’appel d’une fonction d’initialisation de la donnée, si choisi dans l’IHM une lecture depuis un fichier (NETCDF)

Quelques Spécificités PALM repose entièrement sur MPI, version complète avec MPI-2 ou version « dégradée » avec MPI-1 (recommandée pour le HPC) Environnement hétérogène et codes commerciaux : fonctionnalités par sockets IP et unités miroir => Déploiement sur tous types de machine : Linux, NEC, CRAY, IBM, SGI, BLUE GENE, Mac OS X … sauf WINDOWS

OpenPALM = PALM & CWIPI CWIPI : alternative à MpCCI développée par l’ONERA, CWIPI peut être utilisé sans PALM Basé sur la définition de maillages non structurés, partitionnés ou non Gestion des communications entre codes Interpolation 1D, 2D, 3D surfacique et 3D volumique Gestion des interpolations utilisateurs via des callback Sorties graphiques : partitionnement des maillages, identification des points non localisés, champs échangés Interface C/C++, Fortran et Python Intégré dans PALM

Quelques dates 1998 : idée de PALM, Philippe Courtier MF pour l’assimilation de données 2000 : Première maquette PALM_PROTO pour Mercator Océan 2002 : PALM_Research, version SPMD simulant du MPMD 2004 : PALM_MP, vrai MPMD 2011 : Open source, collaboration avec l’ONERA, interpolation spatiale via CWIPI

Bien démarrer avec OpenPALM
Instrumentation d’un code de calcul Bien démarrer avec OpenPALM Se former à OpenPALM : il est vivement conseillé d’avoir fait les sessions de formation du manuel -> formations de 3 jours au CERFACS -> prochaine session : avril 2014, au CINES à Montpellier, inscription sur le site de PRACE un mois avant (non ouvert) - gratuit -> il est possible de faire les différentes sessions « à la maison » tout est dans la distribution d’OpenPALM -> « réviser » si l’utilisation de PALM n’est pas consécutive à la formation Connaitre son code à PALMer, au besoin se faire aider des développeurs Avancer pas à pas

Instrumentation d’un code de calcul
1) En premier : faire tourner le code seul sous PALM Tous les codes peuvent tourner sous PALM, sans grande modification Question préalable à se poser -> Qui gère les sources ? Comment faire remonter l’instrumentation dans la version officielle du code? Au besoin : utiliser une clé de pré compilation (USEPALM) pour faciliter la maintenance du code, ceci permet de garder une même version du code avec et sans PALM. Identifier et maitriser un minimum le processus de compilation du code, fichier Makefile ? Identifier les librairies (*.a *.so) nécessaires au code Ajouter un niveau supplémentaire d’appel au niveau du programme principal

1) Faire tourner le code seul sous PALM Fichier main_titi.f90 à ajouter program titi call a_titi() end program titi Fichier titi.f90 subroutine a_titi() ! exemple call sub_1(…) call sub_2(…) end Fichier titi.f90 program titi ! exemple call sub_1(…) call sub_2(…) end Autres fichiers : sub_1.f90 sub_2.f90 Compilation et modification du fichier Makefile Ajouter des règles dans le fichier Makefile pour obtenir soit le programme sans PALM soit une librairie pour PALM > f90 –c titi.f90 –o titi.o > f90 –c main_titi.f90 –o main_titi.o > f90 –c sub_1.f90 –o sub_1.o > f90 –c sub_2.f90 –o sub_2.o > f90 main_titi.o titi.o sub_1.o sub_2.O –o titi > f90 –c titi.f90 –o titi.o > f90 –c sub_1.f90 –o sub_1.o > f90 –c sub_2.f90 –o sub_2.o > ar -rv titi.o sub_1.o sub_2.O –o libtitipalm.a résultat : exécutable titi sans PALM résultat : librairie libtitipalm.a

1) Faire tourner le code seul sous PALM Cas particulier d’un code déjà parallèle MPI : !program N3SNatur subroutine N3SNatur() USE palmlib !* PALM interface ! ! CALL MPI_Init(…) ! CALL MPI_Comm_rank(MPI_COMM_WORLD, il_rank, err) CALL MPI_Comm_rank(PL_COMM_EXEC, il_rank) CALL PALM_Get (‘recv_field_space’, ‘RECV_FIELD’, time, tag , array, error) … ! CALL MPI_Abort() CALL moncode_abort() ! CALL MPI_Finalize(…) End Subroutine N3SNatur  Ne plus faire l’appel  Utiliser les communicateur donné par PALM  Gérer correctement les arrêts subroutine moncode_abort() #ifdef USEPALM integer :: err call PALM_Abort(err) #else call MPI_Abort() #endif end  Ne plus faire l’appel

1) Faire tourner le code seul sous PALM Créer la carte d’identité du code !PALM_UNIT –name titi\ ! functions {f90 a_titi}\ ! object_files {libtitipalm.a}\ ! comment {test titi sous palm} Puis une application PrePALM lançant cette seule unité Le code fonctionne sous PALM ! Remarque : pour ne pas mélanger les fichiers d’entrée et de sortie des différents codes il est judicieux d’utiliser le champs « Execution working directory » de l’instance de l’unité qui permet de faire tourner chaque code dans un répertoire particulier.

2) Les échanges de données L’instrumentation des échanges de données est d’autant plus rapide : qu’on connait le code qu’on a bien répertorié ce qu’on doit envoyer ou recevoir des autres unités Identifier les quantités physiques à échanger, leur fréquence d’échange : une seule fois ? au début du code ? à la fin ? dans une boucle ? Identifier les variables informatiques contenant ces quantités, sous quelle forme ces données sont-elles accessibles : common f77? modules f90 ? variables locales ? Dans le code, identifier les types informatiques des objets à échanger: scalaires ? types dérivés ? tableaux ? pour les tableaux la taille est-elle connue au démarrage ? Ceci permettra de définir les espaces PALM

2) Les échanges de données Définir le type des espaces : statiques ? paramétrables avec des constantes PrePALM ? dynamiques ? Ecrire la carte d’identité, nommer les espaces, les objets, relire la carte d’identité du code dans PrePALM. Plutôt que d’éparpiller les appels PALM_Put/Get partout dans le code, préparer des sous programmes spécifiques pour PALM : en général trois routines « utilisateur » suffisent : une dans la phase d’initialisation, une dans la boucle temporelle (si elle existe), une à la fin du code. Utiliser la fonction Utilities -> Generate source code from id_card de PrePALM pour faire du copier/coller des PALM_Put/Get dans ces routines utilisateurs

Quelques exemples d’utilisation
Assimilation de DOnnées dans les MOdèles de Chimie Atmosphérique Fédération des principaux acteurs de la communauté scientifique SA, LA, LSCE, LPCE, LMD , IPSL, CERFACS, L3AB, CNRM, ACRI, CNES Projet soutenu par le PNCA Utilisation d’un outil commun pour Échanger facilement des composants : modèles, opérateurs d’observation Échanger des méthodes 3d_fgat 4d_var L’algorithme d’assimilation est simplement redéfinit dans l’interface graphique PrePALM, aucune ligne n’est modifiée dans le code source des unités. On ajoute certaines unités comme le modèle adjoint et le linéaire tangent

Quelques exemples d’utilisation
Chaine d’optimisation

Application mode IP (J. Richard)
Monde MPI DRIVER Miroir MARC Miroir AVBP MARC AVBP

Expansion urbaine et impact du changement climatique à l’horizon 2100
Le projet ACCLIMAT a bénéficié d’une aide de la Fondation de Coopération Scientifique STAE Toulouse GAME AUAT CERFACS ENM-CIRED GEODE GRECAU IMT - ONERA Projet RTRA/STAE ACCLIMAT : plateforme de modélisation de la ville Toulouse Expansion urbaine et impact du changement climatique à l’horizon 2100  Données échangées entre les modèles à chaque pas de temps Génération des conditions climatiques à l’échelle de la ville Température Humidité Flux radiatifs Précipitations Expansion urbaine et génération de la forme urbaine Conditions météo NEDUM Carte des zones urbanisables Génération d’îlots urbains et leur évolution GENIUS SURFEX Surfaces nouvelles à urbaniser (Quantité de changement) Attractivité Cartes de l’évolution de densité de bâti et population Carte et paramètres des îlots urbains SLEUTH* Simulation du climat urbain et calcul des impacts énergie-climat

Expansion urbaine et impact du changement climatique à l’horizon 2100
Le projet ACCLIMAT a bénéficié d’une aide de la Fondation de Coopération Scientifique STAE Toulouse GAME AUAT CERFACS ENM-CIRED GEODE GRECAU IMT - ONERA Projet RTRA/STAE ACCLIMAT : plateforme de modélisation de la ville Toulouse Expansion urbaine et impact du changement climatique à l’horizon 2100 Modèles très différents: Socio/économique NEDUM : (matlab) Géo-morphologique SLEUTH (C) Atmosphère : MésoNH (Fortran //) Sols : Surfex (Fortran) Interpolation géophysique

Towards Predictive Simulation of Wildfire
Spread Using Data Assimilation and Uncertainty Quantification M. Rochoux, S. Ricci, D. Lucor, B. Cuenot, A. Trouvé Propagation model of the fire front Correct model parameters (vegetation, wind) to correct the ROS assimilating front position observations with an Ensemble approach using Parasol-OpenPALM (Rochoux et al. 2012) Burnt vegetation Unburnt vegetation Front Rate of spread Γ Airborne observations of the front position Data from Ronan Paugam, Dept. Of Geography, King’s College of London

TURBO-AVBP Exemples d’applications
Utilisateurs : CERFACS, IMFT, Sherbrooke University… Couplage de plusieurs instances d’AVBP 38

OpenPALM en résumé Un coupleur dynamique des codes parallèles
Conçu pour réaliser des algorithmes complexes (ou non), Avec un grande flexibilité, Faire discuter des codes (parallèles) qui tournent en même temps ou pas Couplage de codes, Algorithmes d’assimilation de données, Optimisation, Post-traitement en temps réel, UQ, … Des formations organisées régulièrement au CERFACS, prochaine session : 28-30 avril 2014, au CINES à Montpellier, inscription sur le site de PRACE (non ouvert)

Apports du CERFACS sur le projet Aqui-FR
Formation des utilisateurs, session dédié ? Support sur OpenPALM - choix de la version à installer (MPI-1 ou MPI-2) - installation d’OpenPALM - hotline Conseils sur l’instrumentation Optimisation si nécessaire

Thierry Morel, morel@cerfacs.fr Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry.

Présentations similaires

Présentation au sujet: "Thierry Morel, morel@cerfacs.fr Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Thierry Morel, morel@cerfacs.fr Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry.

Présentations similaires

Présentation au sujet: "Thierry Morel, morel@cerfacs.fr Un coupleur dynamique de codes parallèles pour les applications multi-physiques ou multi-composants CERFACS-ONERA Thierry."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back