081022-lego-PARIS

Nouvelles de PARIS et
État d’avancement des briques
Christian Perez – Toulouse – 22 octobre 2008
News PARIS/GRAAL

Migration de PARIS à GRAAL

Hinde Bouziane, ATER
 Julien Bigot, doctorant
 Christian Perez

STKM (suite de LEGO)

Étend le modèle STCM avec le support de squelette



STKM: Spatio-Temporal-Skeleton component Model
Papier à CBHPC’08, Kalrsruhe
Implémentation au-dessus de SCA/Tuscany/Java
2
WP2: Modèles de programmation

WP2: Modèles de programmation



4 taches





Responsable: PARIS
Équipes impliquées: PARIS, GRAAL, IRIT-TLSE
T2.1: modèle de composant et partage de données
T2.2: modèle de composant et dynamicité
T2.3: modèle de composant et codes patrimoniaux
T2.4: modèle unifié
WP2:

Délivrable 2.1 : Rapport décrivant le modèle unifié.


1/1/2008
Délivrable 2.2 : Intergiciel LEGO (environnement unifié qui
valide la tâche 2.4)

31/12/2008
3
Point sur l’état d’avancement
des briques
B16 - JuxMem

Status: Ok
5
B2 - ADAGE

Mise à jour du logiciel

Bug fixes
 Externalisation



adaptateur d’applications (aka plugins)
planners
Status: Ok
6
B19 – CCM Master-Worker

Intégration du paradigme MW dans l’interpréteur

Basé sur un composite « transformateur »
 Composant JAVA qui génère son contenu à l’exécution

Status: ok
master
master
#workers &
policy pattern
selection
Round-Robin
Worker
Worker
worker
Collection
Programmer view
RR, LB
DIET
Worker
Worker
Worker Worker
Execution view
7
B20 – CCM Workflow

Interpréteur fonctionnelle de STCM

Moteur d’exécution du workflow centralisé

3 backends courant

affichage des actions
 Composant JAVA home-made
 Composant CCM

Backend CCM


Liaison workflow-composant (execute)
Génération CAD

au déploiement
 Lors de l’instanciation d’un composant par le workflow engine

Liaison ADAGE


Objet ADAGE dans l’interpréteur
Utilisé par le backend CCM pour (re)déployer les composants
8
B2/B12 – ADAGE/CERFACS

Validation

Déploiement application CERFACS avec ADAGE



CCM (Master & worker), Juxmem (gestion fichier entre mois)
MW: proxy pour l’instant, DIET « facile » à faire
Caractéristiques

Simulation mois/post-pro séparée



Le master execute le schedule qu’on lui donne
Objectif: utiliser un scheduling « GRAAL »
Possibilité de checkpointer un run en cours

Il existe une API checkpointe, le restart est à coupler avec le
scheduling qu’on passe au master
 Objectif: mettre en avant la simplicité/souplesse offerte par JuxMem
 Utilisation d’un ForEach parallèle
 En cours de finalisation
 Objectif
 avoir un workflow un peu plus compliqué
 Étudier la dynamicité des ressources (post LEGO)
9
Demo ?