Couplage de Codes Cours IS 342 -...

1

Couplage de Codes

Cours IS 342

Olivier Coulaud

[email protected]

11/12/2013 IS342 - Couplage de Codes

Plan

n  Introduction n  Motivation n  Quelques exemples

n  La problématique du couplage n  Type de couplage n  Différentes stratégies n  Quelques problèmes

2


Plan

n  Aspects informatiques n  Approche Parallèle : PVM, MPI, PACX-MPI, PVMPI, PLUS n  Approche Grille : Globus, Legion, MPICH-G n  Approche Distribuée

n  Objets Distribués : CORBA, PaCO++ n  Composants : CCM, CCA

n  Quelques exemples : n  Approche multi échelles

n  PUPIL n  Libmultiscale n  SIMBIO

n  EPSN n  Climatologie

3 11/12/2013 IS342 - Couplage de Codes

Quelques rappels sur la simulation

Simulation ? L'objectif est d'étudier un phénomène physique

écoulement, propriétés des matériaux/ molécules, balistique, … Différentes étapes

1.  Modéliser le phénomène en équations 2.  Discrétiser les équations : nombre d'inconnues

1.  Grille, triangulation, points 2.  Schéma explicite ou implicite (résolution d'un système)

3.  Écrire un schéma/algorithme pour résoudre le système discret 4.  Écrire le programme (mpi, openmp, threads, …) 5.  Valider le programme, puis le modèle physique

4

2


Motivation

Pourquoi faut-il coupler des codes ? Composants indépendants Interaction entre composants

n  Simulations de plus en plus complexes : n  3d avec une physique de plus en plus complète, n  haut degré de fidélité, massivement parallèle, n  développement rapide

Systèmes isolés

M1 MN ….

Systèmes complexes

M1 M3

M2

5

Deux types d'applications : n  Multiphysiques : le modèle va réagir avec l'extérieur

n  Modèle climatique, fluide structure, fusion thermonucléaire contrôlée, hydrologie souterraine,

n  Multiéchelles : interaction entre les échelles (loi physique non valable, …)

n  Prédiction du temps, biologie, physique des matériaux, ….

On parle de modèles couplés

11/12/2013 IS342 - Couplage de Codes 6


Motivation

Pourquoi faut-il coupler des codes ?

n  Pas d'expertise dans tous les domaines.

n  Difficile de gérer un code monolithique n  Beaucoup de paramètres pas utiles. n  Maintenance, nouveau développement. n  Difficile de recherche une erreur.


Quelques exemples (1)

n  Réutiliser les codes existants pour réaliser une application complexe n  Aéroélasticité : couplage Mécanique de fluides, mécanique des solides

Aéronautique, biomédical, ….

Couplage frontière :

Gestion du déplacement des deux maillages. Interpolation des données du modèle 1 pour le modèle 2.

8

3



n  Couplage multi échelles : propagation d'une fissure Impossible d'étudier le phénomène : (5 µm)3 ~ 1013 atomes

Modèles : élasticité, atomique, quantique

Équation de Schrödinger R3N. Problème aux Valeurs propres non linéaire.

Oxydation, Casser des liaisons e.

Dynamique moléculaire. Équations de Newton, corps.

Élasticité linéaire, éléments finis.



n  Météo, climatologie, … n  Beaucoup de physiques

différentes (multi physiques) n  Modèles

n  Océan n  Atmosphérique

n  Chimie n  Evaporation / précipitation n  Nuages

n  Végétation n  Glace

n  Assimilation de données

10


n  Partager les expertises sans donner les codes Code = capital, savoir faire d'une entreprise

Construction d'un satellite

Mécanique des structures

Thermique

Optique

Dynamique

Problèmes : •  Interfaces des codes •  Sécurité

•  Identification •  Intégrité, confidentialité des données - cryptage

Problème de type calcul distribué, Grid computing


Réseau partagé Société A

Code A

Société B

Code B

Échanger des informations


Les applications du 21ième siècle

Discrétisation

Solveurs Algébriques

Parallèle I/O

Grilles

Data Réduction

Physiques Modules

Optimisation

Dérivation numérique

Collaboration

Diagnostics Pilotage

Visualisation

Solution Adaptive

Les Logiciels de simulations Numériques deviennent de plus en plus complexes et interdisciplinaires

12

4


Simulation numérique avancée MA2819KA - Jacques Hervé Saiac


n  Cela demande d'intégrer des bibliothèques développées par d'autres équipes n  Ressources locales sont limitées et l'expertise peut ne pas exister n  Pas de contrôle des décisions pour développer les fonctionnalités de la

bibliothèque. n  Problème d'interopérabilité des langages (f77, C, C++, Python, Java, f90)

n  Les techniques pour les petits codes ne passent pas à l'échelle - 500K lignes

Deux approches logicielles n  Spécifique/ ad-hoc

n  Générique

14

La problématique du couplage


Type de couplage

n  Les types de couplage physique n  Mono physique mais multi domaines (couplage par les C.L.) n  Multi physiques, mono domaine (couplage par les termes sources) n  Multi physiques, multi domaines (climatologie, prédiction du temps, …) n  Système multi échelles

n  L'algorithmique du couplage est important n  Consistant, conserver les propriétés n  Le revisiter pour avoir plus de parallélisme

n  Séquentiel (algorithme de Gauss Seidel) n  Parallèle

16

5


Séquentiel Parallélisme

A

B

C A B C

A B C

Une itération Deux itérations

Exemple : Algorithme de Schwarz additif versus multiplicatif

Type de couplage

Compromis entre la vitesse de convergence de l'algorithme et la vitesse d'exécution du code

Synchronisation forte Synchronisation faible


n  Standardiser les interfaces des codes Réutilisation, Structure de données

n  Les différents paradigmes de parallélisme

La problématique du couplage (3)

SPMD - MPI SPMD - OpenMP

Compatibilité, interopérabilité

SPMD - Hybride

18


Différentes stratégies (1)

Plusieurs approches possibles : 1.  Implanter ex nihilo le phénomène couplé :

n  Complexe du point de vue physique, numérique, informatique : risque d'échec élevé.

n  Simplification potentielle de certains effets intervenants dans le système couplé.

n  On ne réutilise pas le patrimoine de codes développés depuis 30 à 40 ans.



2.  Fusion de codes :

•  Difficile : chaque code a sa propre logique de développement, de maintenance corrective/évolutive.

•  Perte d'indépendance des codes.

•  Multiplication potentielle des versions des codes intervenant dans plusieurs systèmes couplés.

20

6



3.  Couplage « à la main » •  Utilisation de codes existants ou développement de codes mono

physique (moins lourds). •  Développement de « filtres » (convertisseurs) souvent très spécialisés. •  Difficulté de gérer le processus global.

Code B

Code A

fichiers fichiers

Filtre 1

Filtre 2

fichiers fichiers Data Data

Data Data



n  Problème : n  Maîtriser la complexité de la mise en œuvre du couplage. n  Réutiliser les codes existants pour les coupler à l'image des processus physiques. n  Intervenir le moins possible dans les codes. n  Préserver l'indépendance des équipes de développement.

n  Solution : utiliser un outil intermédiaire appelé coupleur de codes qui prend en charge les échanges de données et les synchronisations n  adapté aux types de simulations envisagées, n  adapté aux codes écrits en FORTRAN, C, C++, …, n  portable sur de nombreuses plates-formes matérielles, n  permettant les couplages distribués en réseau, n  exploitant le parallélisme éventuel du couplage .

22


Réalisation d'un code monolithique :

Complexité et souplesse (1)

Fonctions éventuellement récupérées de codes existants

La boucle de calcul (schéma de calcul) est figée dans le code. Peu ou pas de souplesse.

Fonction de calcul

Fonction de calcul

Fonction de calcul

Programme principal

Appel des fonctions …

Pour t = t0,…


Codes séparés avec boucles de calcul internes :


Publication

Consommation

Publication

Consommation

•  Intrusion minimale dans les codes : il faut repérer les données à exporter/importer, et les boucles de calculs ou réaliser les opérations

•  Boucles de calcul interne => certaines simulations ne seront pas possible

Couplage gros grains

Publication

Consommation de données de données de données

Code 3 Pour t = t0,3, …



24

7



Codes découpés en « composants » et boucle de calcul externe :

Nécessite de découper en composants composant = objet ou composant

Externaliser la boucle Utiliser un environnement dédié

(CCA, Salomé, CCM,…)

Comp. 1 Comp. 2

Comp. 3

« Code 1 »

Comp. 4 Comp. 5

« Code 2 »

Pour t = t0,…

Appel de Comp. 1 Appel de Comp. 3 Appel de Comp. 4 …

Outil de couplage

25

Taxinomie du couplage

4 notions : Monolithique : force brute, fusion manuel des codes Ordonnancement : un model exécution Independent;

La sortie d'un code devient les entrés d'un autre

Basé communication : appels send/receive Point de couplage dans le code

Basé Composant : modèle de code modulaire constitué de composants avec des interfaces standardisées


Taxinomie

Monolithique


for i=1,nx for j=1,ny call dyn() call update() end for end for

for k=1,z call phys1(k) call phys2(k) end for

for i=1,nx for j=1,ny call dyn() for k=1,z call dyn() call phys1(k) call phys2(k) call update() end for end for end for

Ordonnancé

Model A Model B

Model C

Model D

27

Taxinomie

Basé communication


Basé composant

for i=1,nx for j=1,ny call dyn() call send (X) call update() end for end for

for k=1,z call phys1(k) call receive(X) call phys2(k) end for

28

8

Une grande variété de technologies :

High performance coupling (MCT, OASIS, ESMF, CCA, HLA) Loose coupling / Interoperability (FRAMES, OpenMI) Object-oriented frameworks (OMS) GUI / Visualization (TIME) Scientific workflow engine (Kepler) Architectural standards (CCA, HLA, Salome) Community development initiatives (CHyMP)

H. R. A. Jagers, "Linking Data, Models and Tools: An Overview," in International Congress on Environmental Modelling and Software Modelling for Environment's Sake, Ottawa, Canada, 2010.


Quelques problèmes


n  Langage de « coordination » pour le couplage n  Décrire les enchaînements des programmes n  Décrire l'accès aux données

n  Redistribution des données entre deux codes parallèles

n  Vision informatique du couplage n  À plat : monde du parallélisme (MPI) n  Hiérarchique : mode des objets ou des composants

n  Déploiement n  Lancement, batch, pare-feu, …

Les difficultés


Échanger entre code parallèle des données surfaciques, volumiques

n  Communications efficaces – éviter les goulots d'étranglement n  Prendre en compte les hiérarchies des réseaux

Des solutions souvent ad hoc : n  Tableaux, matrices denses n  Distribution de type HPF : bloc cyclique

Code A Code B

La redistribution : MxN

32

9


La redistribution

Une approche généricité de la redistribution n  Description des données

Distribution entre les processeurs, agencement mémoire dans un processeur

n  Construction de la matrice de communication

n  Ordonnancement des messages Redécoupage pour optimiser les débits, …

n  La couche de communication n  Corba, MPI, ….

Matrice de communication

Description des Objets

Transferts des données en parallèle

Ordonnancement

Redistribution Symbolique

Données parallèles

Ordonnancements des communications

Exemple: bibliothèque RedGrid : RedSym + RedCorba


Composant séquentiel process

Composant parallèle

process

processus processus processus processus process


Composant séquentiel


middleware

Une approche plus moderne

n  Objets distribués / composants n  Structuration de l'application n  Encapsulation des codes

n  Couplage de codes parallèles n  Interconnexion des objets /composants process

process

process process

process process

process

process

process

process

process process

Code 1

Code 2 Code 3

Approche parallèle Utilisation des exécutifs conçus pour la

programmation parallèle.

Structuration des applications (1)

n  Structuration des applications/ hiérarchisation des communications

34


n  Déploiement de l'application n  Placement de l'application sur les machines

n  Système de batch n  Pare-feu

n  Statique versus Dynamique n  Sécurité : Identification, cryptage, intégrité des données

Structuration des applications (2)

Grappe de PC

SAN

SAN

Grappe de PC

LAN

WAN

Supercomputer Visualisation


process


process





middleware

process process

process process

process process

process

process

process

process

process process

Code 1

Code 2 Code 3


Grappe de PC

SAN

SAN

Grappe de PC

LAN

WAN

Supercomputer Visualisation

process process

process process

process

process

process

process

process

process

process process

<<< Code 1

Code 2 Code 3

Approche Parallèle du Couplage

n  Réutilisation des exécutifs conçus pour la programmation parallèle n  Une grille de calcul est un calculateur parallèle virtuel, la programmation

par échange de messages s'impose…

36

10


Grappe de PC

SAN

SAN

Grappe de PC

LAN

WAN

Supercalculateur


process


process





middleware

Visualisation

Approche Objets Distribués du Couplage

n  Objets distribués / composants n  Structuration de l'application, encapsulation des codes

n  Couplage de codes parallèles n  Interconnexion des objets / composants


Quelques solutions de couplages

38


Le Couplage de Codes

Technologies issues de deux mondes différents n  Parallélisme

n  pour supporter des codes de simulations à haute performance n  message passing (MPI, PVM), Pthreads, OpenMP, HPF, DSM, etc. n  plusieurs projets visant à étendre MPI pour supporter le distribué

(PACX, PLUS, MPI2, coupleur, ....) n  Distribué / réparti

n  pour supporter l'exécution de codes de simulation sur des ressources de calcul variées

n  technologies RPC, client/serveur, objets distribués (Java/RMI, CORBA)

n  effort à faire pour que ses technologies supportent le calcul haute-performance, nouveaux concepts à définir...

39

Approche Parallèle

Utiliser le même protocole de communication que celui des applications

11

Rappels sur MPI & PVM


L’échange de Message

n  Le moyen le plus efficace de programmer les machines parallèles à mémoire distribuée

n  L'utilisateur a la complète maîtrise de la parallélisation (équilibrage de la charge, distribution des calculs et des données)

n  Les meilleures performances, très bonne flexibilité

n  Portabilité

n  Mais c'est dur, « assembleur » du parallélisme !!!

42


Problème d'Interopérabilité du monde MPI

n  Connecter différents MPI constructeurs n  utiliser la meilleure implémentation sur chaque architecture

n  Quelques implantations de MPI supportent des machines et des réseaux hétérogènes n  MPICH, MPICH-G, LAM – MPICH2, OpenMPI, …

n  Mais l'interopérabilité ne fait pas partie du standard MPI n  Plusieurs difficultés

n  incompatibilité des différents MPIs constructeur n  communications entre machines hétérogènes (conversion de

données durant le transfert) n  garder la même API du point de vue utilisateur

51

MPI 2 ASPECT DYNAMIQUE


12

Process Creation and Management

n  MPI-1 application is static n  MPI-2 : process creation after MPI application has started n  Motivation: - Task farming applications - serial applications executing parallel codes - To be friendly to the PVM users

n  Communication between new processes and existing application

n  Communication between 2 MPI applications


Process Creation - API

MPI_COMM_SPAWN(command, argv, maxprocs, info, root, comm, intercomm, array_of_errcodes)

IN command IN argv IN maxprocs IN info - a set of key-value pairs telling the runtime system where and how to

start the processes (handle, significant only at root) (MPI_INFO_NULL can be used)

IN root - rank of process in which previous arguments are examined (integer) IN comm - intracommunicator containing group of spawning processes OUT intercomm - intercommunicator between original group and the newly

spawned group (handle) OUT array_of_errcodes


API

MPI_COMM_GET_PARENT(parent) OUT parent - the parent communicator MPI_COMM_SPAWN_MULTIPLE(count,

array_of_commands, array_of_argv, array_of_maxprocs, array_of_info, root, comm, intercomm, array_of_errcodes)

- for starting multiple binaries


Spawn Example – Master/worker

/* master */ #include "mpi.h“ int main(int argc, char *argv[]) { MPI_Init(&argc, &argv); MPI_Comm_size(MPI_COMM_WORLD, &world_size); if (world_size != 1) error("Top heavy with management") MPI_Comm_spawn(worker_program, MPI_ARGV_NULL, 1, MPI_INFO_NULL, 0,

MPI_COMM_SELF, &everyone, MPI_ERRCODES_IGNORE); … … … MPI_Finalize(); return 0; } MPI_COMM_SELF : Predefined communicator containing only the calling process.


13

Example continued

/* worker */ #include "mpi.h“ int main(int argc, char *argv[]) { MPI_Init(&argc, &argv) MPI_Comm_get_parent(&parent); if (parent == MPI_COMM_NULL) error("No parent!"); MPI_Comm_remote_size(parent, &size); if (size != 1) error("Something's wrong with the parent"); … … … MPI_Finalize(); return 0; }


Communication between applications

n  Communication between 2 independently started applications

n  Follows client/server type of communication n  Collective operation n  Operates by means of port names and/or service names


API client/server

n  MPI_OPEN_PORT(info, port_name) - server n  MPI_CLOSE_PORT(port_name) – server

n  MPI_COMM_ACCEPT(port_name, info, root, comm, newcomm) – server

n  MPI_COMM_CONNECT(port_name, info, root, comm, newcomm) – client


API – Service names

n  MPI_PUBLISH_NAME(service_name, info, port_name) n  MPI_UNPUBLISH_NAME(service_name, info, port_name) n  MPI_LOOKUP_NAME(service_name, info, port_name)

Has limited scope than port names Scope defined by implementation


14

Example 1

Server: char myport[MPI_MAX_PORT_NAME]; MPI_Comm intercomm; /* ... */ MPI_Open_port(MPI_INFO_NULL, myport); printf("port name is: %s\n", myport); MPI_Comm_accept(myport, MPI_INFO_NULL, 0, MPI_COMM_SELF, &intercomm); /* do something with intercomm */ Client: MPI_Comm intercomm; char name[MPI_MAX_PORT_NAME]; printf("enter port name: "); gets(name); MPI_Comm_connect(name, MPI_INFO_NULL, 0, MPI_COMM_SELF, &intercomm);


Example 2 – Publishing names

Server: MPI_Open_port(MPI_INFO_NULL, port_name); MPI_Publish_name("ocean", MPI_INFO_NULL, port_name); MPI_Comm_accept(port_name, MPI_INFO_NULL, 0, MPI_COMM_SELF,

&intercomm); /* do something with intercomm */ MPI_Unpublish_name("ocean", MPI_INFO_NULL, port_name); Client: MPI_Lookup_name("ocean", MPI_INFO_NULL, port_name); MPI_Comm_connect( port_name, MPI_INFO_NULL, 0,

MPI_COMM_SELF, &intercomm);



Approche Client/Serveur MPI2

79 11/12/2013 IS342 - Couplage de Codes 80

15

11/12/2013 IS342 - Couplage de Codes 81 11/12/2013

IS342 - Couplage de Codes 82



16





17


IS342 - Couplage de Codes

Résumé n  Serveur ouvre un port n  Serveur publie un nom (publique) n  Client consulte le nom n  Client se connecte au port

n  Serveur supprime le nom n  Serveur ferme le port n  Les deux cotés sont déconnectés

Une autre possibilité MPI_SPAWN, pour lancer les applications. (Regarder l'aspect dynamique de la norme)

90


Limitations

MPI_SPAWN MPI_SPAW

N

Code B

?

Code A

Comment faire communiquer les deux codes ?

91

Couplage

n  Lancement n  Établissement des connexions

n  Connect/accept n  MPI_Intercomm_create

n  Communications via intercomm


intercomm

bootcode

B

A

C

universe

92

18

Solutions dédiées


Solutions dédiées

Coupleur de codes : Générique :

Climatologie : NGC, OASIS, PALM, …

Coupleur Communication

Interpolation

Recherche de voisins

MPI, PVM, …

MpCCI

94

Approche Grille


Approche Grille

Utiliser un super-calculateur virtuelle à l'échelle de la planète

n  domaines administratifs différents, sécurité, déploiements… n  ex. GLOBUS, Legion, Unicore

“10 GFlops, EOS data, 20 Mb/sec -- pour 20 minutes”

Metacomputing Directory Service

GRAM GRAM GRAM

Courtier de ressource

Service d'information : localisation + sélection

Allocateurs de ressources

de GLOBUS

Fork LSF EASYLL Condor etc.

“Quels ordinateurs ?” “Quelle vitesse ?” “Disponibilité ?”

“50 processeurs + stockage de 10:20 à 10:40 pm”

“20 Mb/sec”

GRAM

96

19


GLOBUS

n  GLOBUS “Resource sharing & coordinated problem solving in dynamic, multi-institutional virtual organizations.”

n  Les 4 protocoles clés au cœur n  Sécurité : Grid Security Infrastructure (GSI) n  Gestion de Ressource : Grid Ressource Allocation Management (GRAM) n  Service d'Informations : Grid Ressource Information Protocol (GRIP) n  Transfert de Données : Grid File Transfer Protocol (GridFTP)

http://www.globus.org


MPICH-G2

n  Un MPI pour la grille (GLOBUS) n  Implémentation complète de la Message Passing Interface (MPI) n  MPI est le standard de facto pour le passage de messages, et la

programmation parallèle

n  Permet aux programmes MPI existants de s'exécuter sur la grille sans changements.

n  Documentation n  http://www.globus.org/mpi

98


MPICH-G2

n  Déploiement avec mpirun n  fichier machine à l 'échelle de la grille

popc.ens-lyon.fr/jobmanager-fork 4 kubrick.labri.u-bordeaux.fr/jobmanager-poe 4 farot.ens-lyon.fr /jobmanager-fork 1

n  Meilleures performances grâce à l'utilisation de plusieurs protocoles de communication n  TCP pour les communications inter-machines n  MPI locaux pour les communications intra-machines

n  Conversion automatique des données


Composants Globus en Action

DUROC

fork

P1 P2

GRAM

LSF

P1 P2

GRAM

LoadLeveler

P1 P2

GRAM

MPICH-G

globusrun

mpirun

100

20

Approche Objets Distribués


Approche Objets Distribués

n  Utilisation du concept d'objet distribué (CORBA, Java) n  Programmation par objet à travers un réseau de façon transparente n  Vers une programmation par composants logiciels

n  Avantages n  Réduire la complexité par une approche hiérarchique

n  Inconvénients n  Performance des courtiers d'objets n  Nécessite des extensions pour supporter des objets parallèles

102

Rappels sur CORBA


Calcul Réparti

n  Casser les structures existantes n  insérer des appels de procédure/de méthode à distance

Appelant

Appelé

Appelant Appelé

Souche Squelette

Network

n  Nouveaux problèmes n  Nommage, localisation, transparence, interopérabilité

104

21


CORBA

n  CORBA (Common Object Request Broker Architecture)

n  standard ouvert pour les applications réparties n  indépendant des fournisseurs et des implantations

n  bus logiciel, orienté objet, interface IDL n  communication par appel de méthode à distance (RMI)

n  Object Management Group (OMG) n  Large consortium international responsable de la spécification de

CORBA n  Technologie mature (plus de 12 ans de standardisation)


CORBA

n  Hétérogénéité n  Multi-langages, multi-OSs, multi-réseaux, multi-fournisseurs n  Interface des objets décrits dans un méta-langage (OMG IDL)

n  Portabilité n  Code applicatif indépendant des implantations CORBA n  Projections standardisées OMG IDL vers langages de programmation

n  ADA, C, C++, COBOL, JAVA, LISP, Python, … mais pas Fortran !

n  Interopérabilité n  Protocole réseau commun entre implantations CORBA (GIOP, IIOP) n  Vers d'autres modèles comme OLE, COM et EJB

n  Transparence réseaux n  sélection automatique du protocole de communication en fonction de la

localisation de l'objet

106


CORBA

souche IDL

Squelette IDL

Object Request Broker (IIOP)

Adaptateur d'objet

client Implémentation de l'objet

Compilateur IDL

Spécification IDL

Transparence vis-à-vis de la distribution et de l'hétérogénéité"

serveur client


Exemple CORBA

interface tty { void print(in string msg); };

class tty_impl : virtual public tty_skel { public: tty_impl() {}; ~tty_impl() {}; void print(const char* msg) { cout << msg << endl; }; };

spécification IDL

implémentation de l'objet

108

22


Invocation de méthode à distance

n  Serveur n  init ORB + POA (1) n  créer l'objet (2) n  récupérer réf. service de nommage (3) n  nommer l'objet et l 'inscrire dans le

service de nommage (4) n  activer l'objet puis attendre des

invocations (5) n  Client

n  init ORB (1) n  récupérer réf. service de nommage (2) n  récupérer réf. objet auprès du service

de nommage (3) n  invoquer une méthode à distance (4)

ORB

Serveur

Client

1 2

3

1

2

3

Service de nommage

5

4 4

ref.print("hello")

109

Couplage de Codes avec CORBA

1.  Approche séquentielle

2.  Approche parallèle

•  ParDis

•  Paco/Paco++


n  De nombreuses implémentations de CORBA sont disponibles n  Produits commerciaux, Open Source, ... n  Interopérabilité assurée entre les différentes implémentations n  Interfaçage avec Java (grâce au protocole IIOP)

n  CORBA permet de réduire le temps passé au développement des systèmes distribués n  Relativement simple à utiliser n  Spécification des interfaces – langage IDL

n  CORBA relativement performant n  latence > MPI

n  Conclusion n  seul standard de programmation répartie possédant la performance acceptable pour

le calcul scientifique !!!

CORBA pour le couplage de codes ?


Couplage avec Corba

n  Avantages n  Réduire la complexité du logiciel n  Évolutif n  Modèle client/serveur n  Coût de développement faible, il suffit de travailler sur l'implémentation

des interfaces.

n  Inconvénients n  Modèle client/serveur – car peu utilisé dans le domaine du calcul scientifique. n  Pas de projection vers le Fortran : nécessite une glue n  Manque de support à la programmation parallèle ie pas d'objets parallèles n  Performance :

n  dépendant des ORB, pas de support autre que TCP/IP n  Utiliser les interfaces statiques pas dynamiques

112

23


Couplage appliqué aux simulations

Code métier

Glue

Méthodes pour la lecture des données, sauvegarde des résultats.

Méthodes pour accéder aux variables du codes

Méthodes de calculs : mailleur, solveur, intégration

n  Principes n  Encapsuler un code séquentiel au sein d'un objet CORBA

n  Passer a un code a appel de procédures à un modèle client serveur n  Casser la structure du code n  En général l'interface se découpe en 3 parties n  Spécification au format IDL


Couplage appliqué aux simulations

n  Les données transmises doivent être décrites en IDL ! n  Il faut bien décrire les interfaces des méthodes n  Pas de standardisation – quelques efforts – CCA, Salomé

n  Les interactions sont réalisées à l'aide d'appel de méthode

114


Exemple

Code : Boucle de calcul en temps

Code 1

Évaluation des forces de convection

Mise à jour des inconnues Évaluation des forces

de diffusion

)(1 nnn XFtXX Δ+=+

Une solution : n  Serveur : Le calcul des forces, la mise à jour des inconnues n  Client : l'enchaînement des calculs

Remarque Un enchaînement souvent séquentiel du calcul des forces


Couplage Appliqué aux Simulations Parallèles

Comment passer à un code parallèle ?

n  Pas de parallélisme dans corba n  Il faut étendre les objets ou refaire un intergiciel de couplage n  Il faut écrire ses routines de redistribution des données

116

24


Encapsulation de Codes MPI dans un objet CORBA

n  Approche Maître/Esclave n  Un des processus d'un code SPMD

agit comme un maître alors que les autres processus sont des esclaves

n  Le processus maître contrôle l'exécution des autres processus au travers de MPI

Code SPMD

Couche de communication MPI

Code MPI encapsulé

Processus MPI esclaves Proc

essu

s MPI

maî

tre

Code SPMD Code

SPMD Code SPMD Code

SPMD Code SPMD

SPMD code

Skel.

POA Stub

Client

ORB

n  Inconvénient n  Une approche pas très « scalable » n  Maître goulot d'étranglement n  Nécessite des modifications des

codes à encapsuler


n  Points clés n  Maître CORBA+MPI (héberge un serveur CORBA) n  client communique via CORBA avec le maître n  communication du maître via MPI avec les esclaves (gather/

scatter)

Approche Maître/Esclave

MPI Communication layer

Encapsulated MPI Code

MPI

Sla

ve p

roce

sses

MPI

Mas

ter

proc

ess

SPMD code

Skel.

OA Stub

Scheduler

Client

CORBA ORB

SPMD code

SPMD code

Disp. Disp. Disp.

SPMD code

118


Modèle distribué

Récepteur Parallèle Émetteur Parallèle

n  Sérialisation des communications n  Modifications des programmes parallèles n  Gestion à la main des distributions

Objet distribué


Inconvénients n  Mélanger des requêtes MPI et Corba

Des conflits si l'on qu'une interface réseau : comment reconnaître un message MPI d'un message CORBA

Solution : projet PadicoTM = framework pour lancer des applications parallèles comme des composants logiciel (ddl).

n  Goulot d'étranglement sur le master comme dans l'approche parallèle

Solution : un serveur par nœud mais coté client comment appeler une méthode sur tous les objets problème de synchronisation (serveur indépendant)

Modèle distribué

Nécessiter des objets CORBA parallèles

120

25


Couplage Parallèle / Parallèle

ORB


Skel. . POA

Impl. Objet

Code SPMD

Objet CORBA parallèle

Skel. . POA

Skel. . POA

Application MPI

...

...

...


Client CORBA Parallèle

Code SPMD

Stub

Code SPMD

Stub

Code SPMD

Stub

Application MPI

Impl. Objet

Code SPMD

Impl. Objet

Code SPMD


Concept d'Objet CORBA Parallèle

n  Objet Parallèle CORBA n  collection d 'objets CORBA identiques (même interface IDL) n  transparence pour le client (même si séquentiel)

n  prise en charge de l'invocation parallèle de méthodes n  redistribution des données

n  ne pas modifier l'ORB ! n  flux parallèle de communication entre objets appartenant aux collections

n  Spécification de l'OMG en nov.2001 Data Parallel Corba n  Modification de ORB n  Pas de spécification sur la gestion des données n  pas d'implémentation disponible.

n  Deux implémentations : n  PaCO++ (Irisa), PARDIS (Los Alamos + Univ. Indiana)

122


Couplage Appliqué aux Simulations

n  Principes n  Encapsuler un code parallèle au sein d'un objet parallèle CORBA n  Les données transmises doivent être décrites en IDL ! n  Il faut pouvoir décrire la distribution des données dans les codes n  Les interactions sont réalisées à l'aide d'appel de méthode

n  Avantages des Objets CORBA Parallèles n  Hérite de toutes les bonnes propriétés de CORBA

n  portabilité, interopérabilité langage et systèmes, etc. n  Assurer la « scalabilité » des interactions entre objets CORBA parallèles

n  Flux de communications parallèles n  Permet de saturer des réseaux à très haut débits qui assure l'interconnexion

des machines n  Pas de goulot d'étranglement comme PACX


Des objets parallèles

Ce que le développeur d'application devrait voir…

… et comment il doit être implémenté

// Objet A

SPMD Proc. SPMD

Proc. SPMD Proc. SPMD

Proc. SPMD Proc.

// Objet O

SPMD Proc. SPMD

Proc. SPMD Proc. SPMD

Proc. SPMD Proc.

… …

o->exemple(m); Objet O

124

26


De CORBA vers CORBA Parallèle...

Envoi de la matrice

Client

Redistribution des données

Client

Objet Parallèle

Serveur

Objet Parallèle Objet Parallèle



Points clés

n  Avoir une vision cohérente des différents objets n  Synchronisation des objets

n  Distribution des données : n  Comment spécifier la distribution des arguments et du retour d'une

méthode n  Être suffisamment générique pour qu'un utilisateur puisse définir sa

distribution

n  Quel sens donner à une exception sur un objet sparallèle

n  …

Nécessite au minimum de modifier l'ORB et/ou d'étendre l'IDL

126


Le projet : PARDIS

n  Start with existing standards (CORBA) n  ORB-based system where objects interact through CORBA IDL

interfaces

IDL specification

Server's application

and package

Client's application and package

PARDIS ORB

Client's stub

Server's stub

Client's RTS

Server's RTS

compiler


PARDIS: Extensions to CORBA

New Concepts: n  SPMD (Collective) object associated with a set of threads

performing services accepted by all of these threads n  Collective invocations n  Asynchronous requests and futures n  Data representation issues:

n  IDL: distributed sequences and sequences dsequence<double,64,(BLOCK, CYCLIC)>

n  distribution templates for both sides of interaction

128

27


PARDIS: Evaluating the Abstraction

n  Exposing a “parallel” interface to an object allows us to transfer data in parallel

n  Comparison of two kinds of interaction: n  Through a “sequential” interface

n  Data is gathered on one node at source and scattered at destination

n  Through a “parallel” interface n  Given the application-specific knowledge of distribution the

data can be mapped directly between N threads of the client and M threads of the server (the MxN problem)


PARDIS: Comparison

131


Object Request Broker (ORB)

POA

Skel.

SPMD Proc.

Object inv.

Stub POA

Skel.

SPMD Proc.

POA

Skel.

SPMD Proc.

MPI communication layer Parallel CORBA Object

Sequential client

Parallel Server

Extended-IDL

Compiler

interface[*:2*n] MatrixOperations { typedef double Vector[SIZE]; typedef double Matrix[SIZE][SIZE]; void multiply(in dist[BLOCK][*] Matrix A, in Vector B, out dist[BLOCK] Vector C); void skal(in dist[BLOCK] Vector C, out csum double skal); };

PaCO: Parallel CORBA Object

n  Une collection d'objets CORBA identique n  Transparent pour le client

n  Invocation à distance parallèle & Data distribution n  Impact sur le standard:

n  Ne modifie pas ORB n  Nécessite des extensions à l'IDL et au service de

nommage


Extensions à CORBA n  IDL (Interface Definition Language)

n  Collection d'objets n  Dimension et topologie de la collection n  Distribution des données n  Opérations de réductions

n  IDL Compiler n  Génération des souches/squelette pour la prise en compte des objets

parallèles

interface[*:2*n] MatrixOperations { typedef double Vector[SIZE]; typedef double Matrix[SIZE][SIZE]; void multiply(in dist[BLOCK][*] Matrix A, in Vector B, out dist[BLOCK] Vector C); void skal(in dist[BLOCK] Vector C, out csum double skal); };

n  Nouveau type de données pour les paramètres tableau distribués n  Extension des séquences CORBA n  Information sur la distribution des données

n  Service de Nommage n  Besoin d'associer une collection de références d'objet à un nom symbolique

133

28


interface[*] Operations { typedef double Matrix[100][100]; void foo( inout dist[BLOCK][*] Matrix A ); };

ORB Sequential Client

Parallel Server

Request0

Request1

Request2

Request3

... pco->foo( A ) ...

Client obj.

Stub

A

foo( A ) Skeleton Server obj.

foo( A )

foo( A )

foo( A )

MPI

Gather/Scatter

Invocation à distance avec des paramètres distribués



POA

Skel.

SPMD Proc.

POA

Skel.

SPMD Proc.

POA

Skel.

SPMD Proc.


Stub

SPMD Proc.

Stub

SPMD Proc.

Stub

SPMD Proc.


Parallel Client

Parallel Server

POA

Skel.

Object inv.

Stub

SPMD Proc.

Stub

SPMD Proc.

Stub

SPMD Proc.



Sequential Server

Parallel Client

Parallel CORBA Object as Client

n  Assignment of remote object references to the stubs

n  Use of distributed data type as operation parameters in the stubs

n  Exchange of data through MPI by the stubs (or the skeletons)

n  To build requests n  To broadcast results

135


PaCO++ : Portable parallel CORBA object

n  Objectives n  No modification to the OMG standard

n  Standard IDL n  Standard naming service

n  Behave like standard CORBA objects n  I_var o = I::_narrow(...);

o->fun(); n  Data distribution managed by the

middleware and not by the users n  At the client or the server side n  Through the ORB

n  Interoperability with various CORBA implementations

CORBA stub

Parallel CORBA stub

Parallel User Code (MPI)

Interface1

ManagerInterface1

Interface1 Implementation

ManagerInterface1

CORBA skeleton

Parallel CORBA skel

CORBA ORB

Interface1

MPI WORLD MPI WORLD

CORBA stub

Parallel CORBA stub & skel.

Parallel User Code (MPI) CORBA interface

CORBA interface

MPI runtime Socket Interface

MPI calls

MPI interface

Socket interface IPOC library

MPI interface

IPCOC interface


PaCO++

n  Objet CORBA parallèle n  Implémentation du modèle de programmation abstrait

n  Extension portable n  Bibliothèques de threads et communications n  Bibliothèques de redistributions et ordonnancements n  Interopérabilité

n  Disponible à cette adresse n  http://www.irisa.fr/paris/Paco++

137

29


Utilisation de PaCO++

// IDL interface MyInterface { void factoriser(in Matrice mat); };

// XML Nom: MyInterface.factoriser Type: Parallèle Argument1: Distribué


// Code SPMD sur le récepteur void factoriser(const Matrice mat) { .... MPI_Bcast(...) ... ;} // Code sur l'émetteur

o->factoriser(m);


Chaîne de compilation

Factoriser.xml Factoriser.idl

Générateur CORBA

Souches CORBA

Générateur PaCO++

FactoriserPaCO.idl Code PaCO++

139


Gestion des redistributions dans PaCO++

ORB

Souche CORBA

Bibliothèque de communication

( MPI) Code applicatif

Code PaCO++


Gestion des redistributions dans PaCO++

ORB

Souche CORBA

Bibliothèque de communication

( MPI) Code applicatif

Gestion des communications 1: Calcul des matrices 2: Calcul des ordonnancements 3: Appels CORBA

Bibliothèque de redistribution 1

Code PaCO++

Bibliothèque d'ordonnancement 1

141

30


Plates-formes d'expérimentations

n  À l'IRISA : n  1 grappe de 16 machines n  1 Gb/s Ethernet n  Switch 100 Mb/s n  2 Gb/s Myrinet 2000

n  À Sophia : n  1 grappe de 16 machines n  100 Mb/s Ethernet

n  VTHD n  Routeur à 1Gb/s

n  Utilisation de PadicoTM

Résultats


Un coupleur : La plate-forme open source SALOME

n  Projet RNTL : n  CEA, EDF, EADS, OpenCascade …9 puis 20 partenaires

n  Plate-forme : n  lien entre les systèmes CAD et les logiciels de calculs n  Système de couplage de logiciels n  …

Post

CAD Modeling

CAD Interface Idealization

Cleaning Healing Attributes

Meshing

Data Sets

Supervision

Solver CAD System

Visualization

http://www.salome-platform.org/

n  Plate-forme de développement du CEA et EDF n  Gros effort de standardisation des interfaces des logiciels/modules

Interface MED

143


SALOME

n  Architecture n  Kernel

n  Interface de l'application n  Cycle de vie des composants n  Module d'échange de données (avec le modèle MED)

n  Modules n  GEOM : conception et édition des géométries n  MESH :génération des maillages n  DATA : Propriétés physique des matériaux n  VISU : Visualisation des résultats n  SUPERV : supervision des calculs

n  Approche data flow

CORBA


Projet ALLIANCES

Stockage souterrain des déchets - ANDRA, CEA et EDF

145

31

Approche Composant


La Philosophie des Composants

147


Limitation des Objets Distribués

n  Absence de vision globale de l'application n  les principaux concepts sont définis au niveau d'un objet individuel n  pas de notion de description globale de l'architecture

n  Difficulté d'évolution n  conséquence de l'absence de vision globale

n  Absence de services n  les services nécessaires doivent être réalisés ''à la

main'' (persistance, sécurité, tolérance aux fautes, etc.) n  Absence d'outils (composition, déploiement) n  Conclusion

n  charge importante pour le programmeur n  incidence sur la qualité de l'application n  une partie du cycle de vie n'est pas couverte

n  Les composants pour répondre à ses limitations !!! 148 11/12/2013


Composants : Description

n  Définition n  module logiciel autonome n  unité de déploiement (installation sur différentes plates-formes) n  unité de composition (combinaison avec d'autres composants)

n  Propriétés n  spécifie explicitement la ou les interface(s) fournie(s) n  spécifie explicitement la ou les interface(s) requise(s) n  peut être configuré n  capable de s'auto-décrire

n  Intérêt n  permettre la construction d'applications par composition de briques de

base configurables et réutilisables n  séparer les fonctions des fournisseur et d'assembleur (conditions pour le

développement d'une industrie des composants)

149

32


Composants : Modèle Générique

Composant

synchrone synchrone

asynchrone asynchrone

Propriété configurables (interfaces spéciales avec accès restreint)

Contraintes techniques (placement, sécurité, transactionnel, persistance…)

Interfaces requises (fournies par d'autres

composants) Interfaces fournies

(fournies par le composant)


Composants : Utilisation

Composition hiérarchique et encapsulation (composants construits, sous-composants)

A1

A B A2

A3 B1 B2

Interfaces d'entrée (fournies) Interfaces de sortie (requises)

Interconnexion de composants (connecteurs, ou objets de communication)

151


Support Logiciel pour Composants

n  Pour assurer leurs fonctions, les composants ont besoin d'un support logiciel

n  Conteneur n  encapsulation d'un composant n  prise en charge des services du système (non fonctionnel)

n  nommage, sécurité, transactions, persistance, etc. n  prise en charge partielle des relations entre composants

(connecteurs) n  invocations, événements

n  techniques utilisées : interposition, délégation n  Structure d'accueil

n  espace d'exécution des conteneurs et composants n  médiateur entre conteneurs et services du système


Mise en œuvre des Composants

Structure d'accueil

Conteneur

Structure d'accueil

Conteneur

Conteneur

Composant

Composant

Composant

Client

Bus logiciel + services (désignation, persistance, transaction, sécurité,etc.) 153

33


Composants : Situation

n  Microsoft n  DCOM & .NET

n  Java n  Java Beans, Enterprise Java Beans

n  CCM (CORBA Component Model) n  Modèle Composant de CORBA (CORBA 3) n  basé sur le modèle objet et les services de CORBA 2

n  CCA (Common Component Architecture) n  Et les composants parallèles ???

n  GRID CCM (basé sur les objets parallèles CORBA 2) n  Concept de composant CCA SPMD, port collectifs, CCA MxN


Today:

Single-purpose, monolithic, tightly-coupled parallel codes

Currently DOE Apps Are: •  One-off, stove-pipe, few

participants But Also:

•  Scalable, and low latency •  Large & rich legacy

investment

Goals •  Enable plug-and-play

parallel simulations •  Establish component

"marketplace" with applications partners

•  Extend commodity component technology for HPC

Challenges •  Practical parallel HPC

component model •  Integrate legacy

software investment •  Connection to Grid

components •  Multi-language

Common Component Architecture

Participants:

ANL

Indiana Univ.

LANL

LLNL

ORNL

PNNL

SNL

Univ. of Utah

Partners:

Climate Modeling

Quantum Chemistry

Combustion Modeling

CCA

Component-Based Scientific Application

Discretization Engine

Implicit Solve

Visualization

Ports

Link

High Performance Component Framework Scientific Components

“MxN” Parallel Data Redistribution

Applications Integration Rob

http://www.cca-forum.org/ccttss

Component Technology for Terascale Simulation Software: Bringing Components to High Performance Computing

155


Common Component Architecture: what we do for you & to you

n  Gain n  Users:

n  Choice of useful software for high-performance computing (HPC) n  In a near mix-and-match, plug-and-play fashion n  Independently developed code works together in parallel

n  Developers: n  Produce code that will find a wider audience n  With consequent fame and maintenance drudgery n  Use other people's code and take credit for it

n  Pain n  Can't continue develop software “unconstrained” n  CCA Constraints:

n  Provide the fences that make good neighbors n  Are small when wrapping well-designed legacy code n  Identify and disallow behaviors that produce incompatibility


n  Component - Encapsulated software object that provides a certain functionality or service and can be used in conjunction with other components to build applications

A component consists of n  an API (abstract interface) and n  one or more component implementations n  common behavior among these components

n  CCA uses a peer component model - No particular component assumes it is “in charge” of the others. Allows the application developer to decide what is important.

By definition components are independent software modules that are composable...

157

34


Existing Component Architecture Standards such as CORBA, Java Beans, and COM do not provide support for parallel components.

DOE Common Component Architecture provides a mechanism for interoperability of high performance components developed by many different groups in different languages or frameworks.

CCA Motivation

Desire to build Science Applications by hooking together drag-N-drop components.

sec 1 10 -6 10 -4 10

-1

CORBA/Java CCA MPI

Latency between components


What have we developed? n  Metaphor from visual programming

(e.g. AVS) n  instead of data-flow ports are linked

with interfaces n  provides/uses design pattern

n  Scripting support for applications n  create Python applications out of

components

n  Scientific IDL spec. n  provides language interoperability

only - not part of the component arch. per se.

n  introspection.

Parallel Framework

Mesh Setup

Link

Eqn Solver

Link

Viz

P

P

P

P

Port

http://www.cca-forum.org/spec

159


Ports preserve the high-performance of direct connections plus the versatility of distributed object systems

n  Allow directly connected interfaces: the next component is one function call away.

n  Adapters will create network-distributed objects out of the same components without altering them.

Component 1

UsesPort

Component 2

Provides-Port

Component 1 Component 2

Provides/Uses Port


CCA develops components & supporting code for direct use in apps

n  Reference Framework n  One unified framework n  Parallel and grid aware

n  MxN n  Data re-decomposition components n  Framework plug-ins

n  Components and Applications

n  Various component prototypes n  service capabilities, discretization, mesh management, linear

algebra, vizualization, etc.

n  Collaboration with other groups to define common interface suites

n  E.g., scientific data interfaces (structured and unstructured)

n  Details: http://cca-forum.org/ccttss/report/Dec01

A A A A

B B B B

MPI

MPI

Proc1 Proc2 Proc3 etc...

Discretization

Grids

Physics Modules

Optimization

Derivative Computation

161

35


A A A A

B B B B

MPI

MPI

Process

Application MPI utilisant CCA pour faire interagir les composants A & B se trouvant dans le même espace d'adressage

Composant A

Composant B

Connexion Directe

Concept de Composants CCA SPMD

Proc1 Proc2 Proc3 etc...


Concept CCA de Port Collectif

composant de visu. parallèle

port collectif connectant M proc. avec N proc.

Coupler des composants parallèles SPMD grâce au concept de port collectif

2 composants SPMD maillage et solveur

163

165

CCA Supports Parallelism -- by “Staying Out of the Way” of it

n Single component multiple data (SCMD) model is component analog of widely used SPMD model

P0 P1 P2 P3

Components: Blue, Green, Red

Framework: Gray

• Different components in same process “talk to each” other via ports and the framework

• Same component in different processes talk to each other

through their favorite communications layer (i.e.

MPI, PVM, GA)

• Each process loaded with the same set of components wired

the same way

• • • •

Any parallel programming environments that can be mixed

outside of CCA can be mixed inside 11/12/2013


n  Simulation composed of multiple SCMD sub-tasks

n  Usage Scenarios: n  Model coupling (e.g. Atmosphere/Ocean) n  General multi-physics applications n  Software licensing issues

n  i.e. limited number of instances

n  Approaches n  Run single parallel framework

n  Driver component that partitions processes and builds rest of application as appropriate (through BuilderService)

n  Run multiple parallel frameworks n  Link through specialized communications components n  Link as components (through AbstractFramework service)

“Multiple-Component Multiple-Data” Applications in CCA

Ocean Atmosphere Land Driver

Coupler Processors

Supplementary material for handouts


36

167

Components only on process group B Group B

MCMD Within A Single Framework

Components on all processes

Application driver & MCMD support component

P0 P1 P2 P3

Framework

Components only on process group A

Group A

See example in the Using CCA module (multilevel parallelism in

quantum chemistry)

• • • • Supplementary material for handouts


Maintaining HPC Performance n  The performance of your application is as important to us as it is to you

n  The CCA is designed to provide maximum performance n  But the best we can do is to make your code perform no

worse, unless we give easy access to new algorithms.

n  Facts: n  Measured overheads per function call are low n  Most overheads easily amortized by doing enough work per

call n  Other changes made during componentization may also

have performance impacts n  Awareness of costs of abstraction and language

interoperability facilitates design for high performance

More about performance in notes


170

•  Lois Curfman McInnes,et al. Parallel PDE-Based Simulations Using the Common Component Architecture. In Are Magnus Bruaset, Petter

Bjorstad, and Aslak Tveito, editors, Numerical Solution of PDEs on Parallel Computers. Springer-

Verlag, 2005. Invited chapter, in press. •  S. Benson, et al. Using the GA and TAO Toolkits for

Solving Large-Scale Optimization Problems on Parallel Computers. Technical report ANL/MCS-

P1084-0903, Argonne National Laboratory, September 2003.

•  Boyana Norris, et al. Parallel Components for PDEs and Optimization: Some Issues and Experiences.

Parallel Computing, 28:1811--1831, 2002. •  David E. Bernholdt, et al. A Component

Architecture for High-Performance Computing. In Proceedings of the Workshop on Performance

Optimization via High-Level Languages and Libraries (POHLL-02), 2002.

Some Performance Results and References

Maximum 0.2% overhead for CCA vs native C++ code for parallel molecular

dynamics up to 170 CPUs

Aggregate time for linear solver component in unconstrained

minimization problem w/ PETSc

Supplementary material for handouts


Example: Computational Facility for Reacting Flow Science (CFRFS)

n  A toolkit to perform simulations of unsteady flames

n  Solve the Navier-Stokes with detailed chemistry n  Various mechanisms

up to ~50 species, 300 reactions

n  Structured adaptive mesh refinement

n  CFRFS today: n  61 components n  7 external libraries n  9 contributors

“Wiring diagram” for a typical CFRFS simulation, utilizing 12 components.

CCA tools used: Ccaffeine, and ccafe-gui

Languages: C, C++, F77 11/12/2013


37

172

Helping Groups Work with Software Some Common Situations: n  Many (geographically distributed) developers creating

a large software system n  Hard to coordinate, different parts of the software don't work

together as required n  Groups of developers with different specialties n  Forming communities to standardize interfaces or

share code How CCA Can Help: n  Components are natural units for

n  Expressing software architecture n  Individuals or small groups to develop n  Encapsulating particular expertise

n  Some component models (including CCA) provide tools to help you think about the interface separately from the implementation 11/12/2013


Schematic of CCA-based molecular structure determination

quantum chemistry application.

Components based on: MPQC, NWChem (quantum chem.), TAO

(optimization), Global Arrays, PETSc (parallel linear algebra)

CCA tools used: Babel, Ccaffeine, and ccafe-gui

Languages: C, C++, F77, Python

Example: Quantum Chemistry n  Integrated state-of-the-art

optimization technology into two quantum chemistry packages to explore effectiveness in chemistry applications

n  Geographically distributed expertise: n  California - chemistry n  Illinois - optimization n  Washington – chemistry,

parallel data management n  Effective collaboration

with minimal face-to-face interaction


COUPLAGE VIA UN CACHE DE DONNÉES


Couplage via un Cache de données

Idée utiliser le format des écritures du code pour échanger entre deux codes via un espace de stockage.


Finite Volume Structural Mechanics

Global Monitor

Runtime Visualization

Small Scale Analysis

Injection Flow Analysis

Distributed Data Hub

175

38

Couplage via un Cache de données

n  Plate-forme n  Network Distributed Global Memory (NDGM) n  …

n  Format de données standardisé

n  NetCDF (network Common Data Form) http://www.unidata.ucar.edu/software/netcdf/

n  HDF5 (Hierarchical Data Format) http://www.hdfgroup.org/HDF5

n  CDF (Common Data Format) http://cdf.gsfc.nasa.gov/

n  …

11/12/2013 IS342 - Couplage de Codes 176 177

Qu'est que HDF5? n  Format de fichier pour des données scientifiques

n  Pour stocker et organiser tous types de données n  Pour partager des données, pour porter des fichiers d'une plate-

forme à une autre n  Pour dépasser une limite sur le nombre et la taille des objets dans

un fichier

n  Logiciel pour accéder à des données scientifiques n  Bibliothèque flexible I/O (parallèle, distant, etc.) n  Un stockage efficace n  Disponible sur presque toutes les plates-formes n  C, F90, C++ , Java APIs n  Outils(HDFView, utilitaires)


Exemple de fichier HDF5

“/” (root)

“/foo”

Raster image

palette

3-D array

2-D array Raster image

lat | lon | temp ----|-----|----- 12 | 23 | 3.1 15 | 24 | 4.2 17 | 21 | 3.6

Table

11/12/2013 IS342 - Couplage de Codes 178 179

Fichier HDF5

n  Fichier HDF5– container pour stocker des données scientifiques

n  Objets principaux n  Groups n  Datasets

n  Moyens Additionels pour organiser les données n  Attributes n  Sharable objects n  Storage and access properties


39

180

HDF5 Dataset

n  HDF5 dataset – data array and metadata n  Data array

n  ordered collection of identically typed data items distinguished by their indices

n  Metadata n  Dataspace – rank, dimensions, other spatial info about dataset n  Datatype n  Attribute list – user-defined metadata n  Special storage options – how array is organized and stored in the

file


Les composants Dataset Exemple Matrice A(7,4,5)

Data

Metadata

Dataspace

3

Rank

Dim_1 = 4 Dim_0 = 7

Dimensions

Time = 32.4

Pressure = 987

Temp = 56

Attributes

Chunked

Compressed

Dim_2 = 5

Storage info

IEEE 32-bit float Datatype


182

Groups

n  Group – a mechanism for describing collections of related objects

n  Every file starts with a root group

n  Can have attributes n  Similar to UNIX

directories, but cycles are allowed

“/”


183

“/” x

temp

temp

/ (root) /x /foo /foo/temp /foo/bar/temp

HDF5 objects are identified and located by their pathnames

foo

Bar


40

184

Groups & members of groups can be shared

/tom/P /dick/R /harry/P

“/” tom dick harry

P R P


HDF5 I/O Library

187

File or other “storage”

Virtual file I/O

Library internals

Structure of HDF5 Library

Object API

Applications


188

Virtual file I/O (C only) •  Perform byte-stream I/O operations (open/close, read/write, seek) •  User-implementable I/O (stdio, network, memory, etc.)

Library internals (C) •  Performs data transformations and other prep for I/O •  Configurable transformations (compression, etc.)

Structure of HDF5 Library

Object API (C, Fortran 90, Java, C++) •  Specify objects and transformation and storage properties

•  Invoke data movement operations and data transformations


41

189

Virtual file I/O layer

n  A public API for writing I/O drivers n  Allows HDF5 to interface to disk, the network, memory, or a user-

defined device

Network"

Network"File Family" MPI I/O" Memory"

Virtual file I/O drivers"

Memory"

Sec2"

File Family"

File"

“Storage”"


NDGM

Développé par J. Clarke (US Army Research laboratory) n  Le concept est semblable à une DSM ou mémoire virtuelle

distribuée n  Transferts de données sont fait via une API n  Programmation comme pour la mémoire partagée

Grand buffer virtuel (mémoire locale ou distante, disque, …) Lire ou écrire des données,



espace d'adressage local du processus

Système à mémoire partagée Serveur de fichiers

0 10M 30M 50M

Stockage physique des données

Serveurs

Clients Put Get

VectorPut VectorGet

Barrière Sémaphore

191

Un exemple de configuration -


Simulation HDF5 Switch

Disk Array

Vis Cluster ParaView

HPC platform / cluster

Optional

NDGM/DSM client

HDF5

192

42

EXEMPLES DE COUPLEURS



Mesh-based parallel Code Coupling Interface

Coupleur générique pour les simulations multi-physiques Grille (structure) - Maillage (CFD)

Couplage surfacique et volumique

Trois composants n  Interface utilisateur : configurer le couplage et lancer la simulation n  Code « adapter » : pour adapter des codes commerciaux via leurs APIs sans

changer les sources. n  Server de couplage : environnement, système de communication entre les

codes, le calcul du voisinage, interpolation Beaucoup de codes commerciaux (18 ) :

Abaqus, Ansys, OpenFoam, Samcef ….

194

MpCCI : architecture


MpCCI : intégration du code (1)

Processus de couplage : envoyer/recevoir des données définies sur un maillage n Maillage : échanger des données entre deux maillages différents

n  Nombre de nœuds, d'éléments, type des données n  Nœuds : identifiant, coordonnées n  Eléments : identifiant, type, nœuds

n Grandeurs physiques n  Accès en lecture des données n  Gestion de l'allocation mémoire des données reçues n  Méthode pour affecter les données au maillage local

n Itération en temps n  Accès en lecture des données n  Gestion de l'allocation mémoire des données reçues


43



Que doit-on mettre dans le code ? n  Initialisation et terminaison n  Étape de transferts

197



Deux parties :

n  Intégration dans la GUI n  Fichiers de configuration : propriétés du code, où lire les fichiers

d'input, lancement du code, …

198



n  Code « adapter » = plugin dans le code de simulation n  Fonctions du driver :

Interface avec les données du code n  Gestionnaire du couplage

n  Fonctions pour communiquer entre le code et le server MpCCI

199

MpCCI : exemple


44


n 

201 11/12/2013 IS342 - Couplage de Codes 202

Le coupleur

•  Bref historique •  Caractéristiques du coupleur

• Quelques applications

Caractéristiques du coupleur PALM

Couplage statique Couplage dynamique

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

Code1

Code2 Code3

Code1 Code2

Lancement parallèle ou séquentiel (chainage)

Lancement en boucle ou sous conditions

Coupleurs classiques Coupleur PALM

Description d'algorithmes complexes

Gestion dynamique des ressources (processeurs et mémoire)

temps Boucle

Code4

condition


45

Lancement de processus

Dans l'IHM Branches parallèles Structures de contrôle Régions Fortran

En dessinant des branches on fait directement du

parallélisme de tâche.

Chaque composant est un exécutable MPI

indépendant.

Interface graphique très intuitive pour l'utilisateur 11/12/2013 IS342 - Couplage de Codes 206


•  Le schéma PrePALM est converti en un arbre pour le driver de PALM. •  Le premier rôle du driver est de schéduler cet arbre pour lancer les composants en fonction des ressources, comme le nombre de processus max. •  Le mécanisme mis en œuvre pour lancer les composants et discuter avec eux est le Spawn MPI-2 ou le mécanisme client/serveur MPI-2. •  Les structures de contrôle, les régions fortran, sont exécutées par le driver de PALM.

Les blocs : optimisation si les composants sont définis comme des subroutines

Les composants peuvent être assemblés dans un seul exécutable. Les blocs contiennent alors les structures de contrôle Mais : • Moins de Spawn • Partage de mémoire globale pour les composants dans un bloc, assemblage de subroutines



Deux niveaux de parallélisme • Parallélisme de tâches = branches de calcul • Parallélisme des composants : gestion des codes parallèles, le nombre de proc de chaque composant est défini dans PrePALM.

PALM repose entièrement sur MPI, version complète avec MPI-2 ou version dégradée avec MPI-1, choix à l'installation

•  Multitasking (MPI) et multithreading (OpenMP) supporté pour les composants

•  Machines visées : calculateurs parallèles, clusters. Donc plutôt un environnement homogène

•  Avantage de MPI : PALM a pu être déployé sur tout type de machine, NEC, CRAY, IBM, SGI, BLUE_GENE L, Linux, Mac OS X, Windows via Cygwin.

•  Environnement hétérogène : fonctionnalités par sockets IP, unités miroir. 11/12/2013


à Pas de spécification concernant l'unité réceptrice ou émettrice des données produites ou consommées dans les codes de calcul

Production de données : SERVEUR

CALL PALM_Put (…)

Consommation de données : CLIENT

CALL PALM_Get (…)

Schéma de communication « end point »

à Communications effectives dans l'interface graphique

46

PALM_Put 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

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 11/12/2013


PALM_Put/Get

Les différentes instances d'un même tableau sont gérées par PALM via un champ time ou tag à l'envoi ou à la réception.

•  ceci autorise l'interpolation temporelle des champs par le coupleur •  et permet de coupler à des fréquences différentes, choisies par l'utilisateur dans l'interface graphique, sans intervention dans le code : PALM_Put fait à tous les instants, mais couplage fait à des instant particuliers

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)


communications

Rôle du driver de PALM

•  répondre à toutes les requêtes Put/Get •  gérer la mémoire pour le stockage temporaire (implicite mailbuff) ou explicite (buffer) des données •  gérer des esclaves mémoire si besoin •  exécuter des opérations élémentaires sur les données •  exécuter certains composants, si demandé •  faire l'interpolation temporelle •  gérer les processus de synchronisation des codes


Les objets distribués

Pour les unités parallèles les objets sont décrits de manière globale Un distributeur permet de définir comment l'objet est réparti sur les différents processeurs

0 1

2 3

Chaque processeur fait PALM_Put de son domaine

Un distributeur est associé à chaque objet

A la communication

PALM fait la redistribution des objets selon les unités et optimise le nombre de communications MPI

0 1 2

3 4 5

6 7 8

9


47

Boîte à outils

Algèbre linéaire Blas, lapack, scalapack Opérations matrices vecteurs

Minimiseurs

Interpolateurs

Grille océan Grille atmosphère

Cgplus Lbfgs

M1qn3 …


Le futur de PALM

n  Passage de PALM en Open-Source

n  Collaboration avec l'ONERA sur les aspects géométriques

n  Collaboration avec le KIT sur les aspects équilibrage dynamique de processus


ADOMOCA VALENTINA


Optimisation de forme MIPTO (INTELLECT D.M.)

Florent Duchaine CERFACS - TURBOMECA


48

Eric Mercier (SNECMA Moteur), Florent Duchaine

Itération 3

Itération 1

Prévision de la température des chambres de combustion


PALM dans le projet ANR corayl Couplage combustion et calcul radiatif

AVBP DOMASIUM

Code CFD - LES Code de rayonnement

Résolution des équations réactives de Navier-Stokes filtrées.

Résolution des équations radiatives en géométrie complexe

Code parallèle Code parallèle

Deux niveaux de parallélisme.

Indépendance des codes de calcul

Schéma de couplage: n itérations CFD par itération de rayonnement

Sources d'énergie. Flux thermiques aux parois. Température.

Espèces

chambre de combustion très hautes températures.

phénomènes radiatifs prépondérants. calcul massivement parallèle.

CERFACS EM2C (Ecole Centrale Paris) LGPSD (Ecole des mines d'Albi)

−7 −6 −5 −4 −3 −2 −1 0 1x 105

0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.11−0.04

−0.03

−0.02

−0.01

0

0.01

0.02

0.03

0.04

X (m)

Y (m

)

Thèse Jorge Amaya


PALM est portable sur la plupart des plates-formes (PC linux, station de travail, supercalculateurs). Site web : http://www.cerfacs.fr/~palm Adresse email :[email protected]

Informations complémentaires


Quelques applications

SIMBIO :

Une plate-forme distribuée pour la simulation moléculaire complexe Multi-échelles :

PUPIL et Libmultiscale L'environnement EPSN :

Pilotage de Simulations Numériques distribuées Climatologie : OASIS, …

49

n 


Bretherton Diagram

222

Couplage de Codes Cours IS 342 -...

Documents

Transcript of Couplage de Codes Cours IS 342 -...