Pour Michel Hello, Tu peux trouver dans ce ppt 3 parties, je te laisse te servir. - L’outil réalisé par GRAAL et pour la communauté de Grid’5000: GRUDU - Les expés de Cosmo - Les expés du CERFACS J’ai fait large pour que tu vois aussi le contexte. Si tu as des questions Partie GRUDU: Partie COSMO: Partie CERFACS:

PARTIE GRUDU

DIET Resources Tool To manage grid resources used by the application Currently only used for Grid'5000 platform. Provides several operations to facilitate the access to this platform. Main goals: Displaying the status of the platform (grid/site/job level) Resources allocation through the use of OAR (v1 & v2 are supported) Resources monitoring through the use of the Ganglia (site/job nodes) Deployment management with a GUI for KaDeploy (multiple sites at a time) A terminal emulator (access frontale/site frontale/job main node connection) A file transfer manager (local/remote and synchronization features)

Grid'5000 Reservation Utility for Deployment Usage Web:

GRUDU – Resources Allocation We are able to reserve ressources (OAR1 & OAR2)  Time parameters, date and reservation walltime  Queue  OARGrid sub behaviour/ Script to launch

GRUDU – Monitoring We are able to monitor the status of the grid/site/a job. We are able to get instantaneous/historical data with Ganglia

GRUDU - KaDeploy/JFTP GUI for KaDeploy jobs deployment File Transfert interface (local remote/rsync on Grid'5000)

PARTIE COSMOLOGIE

Large scale experiment: the DIET/Ramses case Validation of the DIET architecture at large scale over different administrative domains in the framework of the LEGO project (ANR CICG05-11) Grid’5000  Goal : Launch the maximum of Ramses execution (Grid based Hydro solver application developed at the DAPNIA/CEA for cosmological simulations)  Stress DIET over a large number of machine and in a large period of time  But also stress Grid'  KaDeploy image with DIET and all the mandatory tools  12 clusters on 7 sites : 979 machines for 48 hours  1 MA, 12 LA, 29 SeDs  1824 processors dedicated to Ramses

Large scale experiment on Grid’5000: Requests submitted via DIET 1824 processors dedicated to Ramses 59 simulations (33 complete, 26 partial) Equivalent to 368 days on 1 processor GalaxyMaker & MoMaF: Web interface for submission of parameter sweep jobs Workload modelisation for scheduling predictions Workflow / data management

Workflow

Modèle temps exécution GalaxyMaker

Modèle taille outputs GalaxyMaker

Modèle temps exécution MoMaF

Large scale experiment: the DIET/Ramses case Use of the DIET DashBoard:  20 seconds for the reservation of 979 nodes  25 minutes for the deployment with KaDeploy  23 seconds for the deployment of the DIET platform Main difficulties:  Disk space on NFS storage  OmniORB not available on Itanium2  Sites not available for deployment

Conclusion  DIET is a grid middleware designed for scheduling application tasks with a hierarchical architecture  The DIET DashBoard provides to DIET users:  A full-featured framework for experiments  An easy way to manage Grid'5000  The DIET Resources Tool provides to the Grid'5000 community a powerful tool dedicated to the interaction with the grid:  Monitoring  Reservation  Deployment  etc.  The DIET Resources tool exists in a stand alone version known as GRUDU dedicated to the Grid'5000 community

Future Work  Web-based version of the DIET DashBoard Used on the Decrypthon project: WebBoard  GUI for client/server applications design  DIET Data Management interface  Support of other Batch Schedulers (such as LoadLeveler or SGE)  Plugin based architecture ‏

PARTIE CLIMAT

Introduction - Context Climate evolution Global Warming Effect Two problems Long term evolution (need super-computer) Climate model parametrization (need numerous simulations)

Introduction - Motivations The project aims to study the parametrization sensitivity of a climate model A better understanding of parametrization will provide better simulations Once good parameters have been found, we will have the possibility to simulate the climate further in the future Need to perform numerous independent simulations The focus of this talk is the minimization of the execution time of these independent simulations

Ocean-Atmosphere scenarios Climate simulation over the 21st century An experiment is composed of several scenarios A scenario is a chain of 1800 monthly simulations (150 years) Input of (n+1)th monthly simulation is the output of the nth one The scenarios are independent. Month 1 Month 2 Month 1799 Month 1800 ….. A scenario

Outline Introduction Framework Scheduling Strategies Experimental Results Conclusion & Future Work

Grid’5000 a multicore architectue 23 Because of technical limitations, no more than one scenario can be executed on a single node All nodes on Grid’5000 are bi-cores or quad-cores New constraint: the size of a group has to be divisible by the number of cores per node of the cluster Possibility to make groups of 12 processors to reduce loss Loss due to this technical difficulty: Few resources: loss between 1% and 13% More resources: loss between 1% and 5% Lot of resources: no more loss E. Caron - Ocean-Atmosphere scheduling within DIET - APDCT-08

Simulations vs Experiments E. Caron - Ocean-Atmosphere scheduling within DIET - APDCT Accuracy of simulations on 7 experiments Bad with all post-processing tasks at the end (20.8% difference) Good if we consider only main-tasks (6.3% difference) Keeping a resource to execute post- processing tasks during experiment suppresses the simulations inaccuracy Positive difference means the real execution was slower than expected

Outline Introduction Framework Scheduling Strategies Experimental Results Conclusion & Future Work

E. Caron - Ocean-Atmosphere scheduling within DIET - APDCT-08 Conclusion Improve performances in a climate prediction application Modelization of the application Proof of usage of Grid’5000 and Diet Scheduling on real application Scheduling done at two levels Groups of processors at cluster level Distribution of scenarios at grid level Real implementation suffered from technical limitations Simulations are quite precise but we need to keep one resource for post-processing tasks