Nouvelles de PARIS et État d’avancement des briques Christian Perez – Toulouse – 22 octobre 2008

2 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

3 WP2: Modèles de programmation  WP2: Modèles de programmation  Responsable: PARIS  Équipes impliquées: PARIS, GRAAL, IRIT-TLSE  4 taches  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

Point sur l’état d’avancement des briques

5 B16 - JuxMem  Status: Ok

6 B2 - ADAGE  Mise à jour du logiciel  Bug fixes  Externalisation  adaptateur d’applications (aka plugins)  planners  Status: Ok

7 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 #workers & policy pattern selection Programmer view master worker Worker Round-Robin Execution view master RR, LB DIET Collection

8 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

9 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)

Demo ?