WP 5: Applications tests














































WP 1: Services Discovery











Responsable: LIP (E. Caron)

Partenaires impliqués: INRIA Rennes (PARIS), LIP (GRAAL), LoRIA, MIS


Service discovery becomes a challenge in a large scale and distributed context. Heterogeneity and dynamicity are the two main constraints that have to be taken into account in order to ensure reliability and system efficiency. Thereby, in a heterogeneous context, for performance reason, it is needed to provide an efficient load balacing for the service discovery system. Moreover, QoS in such uncertain and dynamic environment have to be ensured by fail-safe mechanisms (self-stabilization and replication). So considered, self-stabilization ensures any time convergence to consistent configuration and replication injects redundancy when the system becomes consistent. All those mechanisms will be validated and implemented. Furthermore, service discovery system will interact with system with schedulers, batch submission systems and storage Resource Broker. So, these component’s exchange protocols have to be formally defined.

Responsable: LIP6 (S. Peyronnet) Partenaires impliqués: INRIA Saclay, LIP (GRAAL), LIP6 L'environnement d'exécution, aussi appelé Runtime, est un élément essentiel dans les architectures de type clusters, grands calculateurs et Grilles. Idéalement, l'environnement d'exécution assure 1) l'agrégation des ressources, 2) l'unification de l'environnement pour que les fonctions soient exécutées par l'ensemble des ressources, 3) la cohérence de la vue du système (les ressources et le contrôleur du système doivent avoir une vision cohérente de l'ensemble du système), 4) le contrôle des ressources individuellement (en détectant leur panne, en les désactivant du système si nécessaire), 5) la communication d'informations et des ordres envoyés aux ressources (à travers des communications de types point à point ou diffusion) , 6) la collection d'information sur les ressources pour établir in état global (si possible) et maintenir la cohérence de perception des ressources. Si ces mécanismes sont bien maîtrisés dans les infrastructures jusqu'à 10.000 ressources, il n'existe pas de résultat, en particulier dans les architectures Petascale, sur ces mécanismes à l'échelle de 100.000 ressources et au-delà. Par exemple, les environnements d'exécution pour MPI sont lancés, même dans les grandes infrastructures, pour une partition réduite de l'infrastructure. L'obtention de performances exceptionnelles (top500), utilisant l'intégralité des ressources sur les très grandes infrastructures, demande des procédures spécifiques, des temps de déploiement et lancement et un niveau de contrôle incompatibles avec une utilisation routinière. Le problème principal réside dans l'architecture du système d'informations (structure de gestion des données réparties) et de signalisation sur lequel repose l'environnement d'exécution. Dans MPICH2, c'est la topologie de ce système (un anneau) qui limite l'extensibilité. Dans OpenMPI, la limite d’extensibilité est due à la centralisation de certains services. Des recherches récentes ont montré que les TBON (Tree Based Overlay Network) et les Graphes Binomiaux avaient de bonnes propriétés comme support pour les environnements d'exécution. Cependant la tolérance aux pannes reste un problème ouvert dans ces systèmes : en effet, il n'est pas envisageable d'appliquer des techniques classiques comme la réplication ou la « rollback recovery » dans des systèmes à plus de 100.000 composants actifs. D'autres domaines de recherche s'intéressent à ce type de structures, comme les systèmes P2P et les overlay networks dont les DLPT font partie. Nous comptons par conséquent étudier les principaux résultats dans ces domaines et les systèmes fonctionnels offrant des caractéristiques proches de celles recherchées, en particulier les DLPT et le système PASTRY. L'objectif de cette tâche est d'étudier une structure de données et de signalisation pour environnement d'exécution extensible, résistante à des pannes massives et fréquentes, efficace pour la communication point à point et multi-point d'information et sur laquelle des services peuvent être greffés. Nous souhaitons en particulier étudier deux approches possibles de tolérance aux pannes : une approche classique de «forward recovery » : autostabilisation et une approche spéculative «probabiliste ».

WP 2: Runtime pour architecture Petascale































WorkPackages

WP 3: Co-scheduling











Responsable: LoRIA (F. Suter)

Partenaires impliqués: LIG, LIP, LoRIA


Because of the variable availibility of resources, due to resource reservations, it is necessary to adapt the scheduling strategies.


While the primary objective of scheduling is usually to minimize the completion time of an application, in the SPADES project we insist on the reactivity of the scheduling decisions and on the low cost restart of a checkpointed computation.


To reach this goal, it is mandatory for the distributed scheduling entities  to collaborate with the resource discovery system and batch schedulers.

Responsable: LUG (O. Richard) Partenaires impliqués: LIP, LoRIA, LUG Dans le cadre de SPADES, les gestionnaires de ressources doivent interagir le plus finement possible avec les mécanismes de découverte de ressources. Dans le cas général, les gestionnaires de ressources peuvent être différents suivant les sites, cette situation pose le délicat problème de l'interopérabilité entre un système de consultation de ressources et les différents gestionnaires de ressources. Plusieurs pistes sont à considérer pour résoudre ce problème, la première est de disposer d'une couche logicielle faisant abstraction des différences de chaque système sous-jacent. Les projets DRMAA et ainsi OGSA-BES sont des tentatives dans ce sens. Une limitation de ces approches est que les fonctionnalités proposées aux couches supérieures se résout à l'ensemble commun des fonctionnalités des systèmes visés, ce qui laisse de coté des fonctionnalités qui peuvent être intéressantes dans notre projet. Une alternative pourrait être soit d'étendre un de ces projets soit de proposer notre propre logiciel d'abstraction. Ces deux voies restent délicates car il est difficile de savoir dans quelles directions et comment vont évoluer ces projets. Il existe une autre alternative que nous souhaitons étudier dans ce projet et qui nous permettra une plus grande liberté d'expérimentation. Il s'agit de coupler en parallèle un gestionnaire supplémentaire commun sur chaque site.

Responsable: CERFACS (E. Maisonnave)

Partenaires impliqués: CERFACS, IN2P3, INRIA Saclay, LIP, LoRIA, LUG


Deux applications tests seront intégrées à la plate-forme SPADES pour le calcul haute performance sur architectures de type Petascale


Cosmologie :

Au cours des 30 dernières années plusieurs dizaines de rayons cosmiques d’énergie excédant 5.1019 eV (énergie dite de la coupure GZK, correspondant à l’interaction des rayons cosmiques avec le fond cosmologique à 3K) ont été observés par des détecteurs terrestres. Ces rayons cosmiques d’ultra haute énergie (RCUHE) demeurent des énigmes à plusieurs titres : ils ne correspondent pas à des sources astrophysiques connues, leur composition chimique est pratiquement inconnue et enfin aucun mécanisme d’accélération conventionnel ne permet d’expliquer leur production et leur propagation jusqu’à la terre. Le but de l’Observatoire Pierre AUGER est de mesurer avec une statistique suffisante les grandes gerbes de particules produites par ces événements dans l’atmosphère pour tenter de répondre aux multiples interrogations soulevées par l'existence de tels événements.


L'objectif de ce détecteur est la mesure de la direction, de l'énergie et de la nature des rayons cosmiques d'ultra haute énergie. L’apport déterminant de l’Observatoire Pierre AUGER à la compréhension des phénomènes qui produisent ces rayons cosmiques d’ultra haute énergie, est une augmentation considérable du nombre d’événements détectés. Cependant cette statistique accrue n’aura un sens que si la mesure des paramètres des gerbes, et plus particulièrement de leur énergie ne souffre pas d’incertitudes importantes. Pour ce faire il est nécessaire de simuler d'une part un grand nombre de gerbes avec différents générateurs (AIRES/MOCCA, CORSIKA,..) et différents modèles de cascades hadroniques, d'autre part que ces gerbes soient aussi réalistes que possible malgré les extrapolations importantes.


Les besoins en calcul sont évalués à au moins 106 heures de calcul / an pour les premières années. Une partie importante de cette puissance de calcul sera fournie par deux ou trois grands centres de calcul dont celui de l’IN2P3 à Lyon et probablement Fermilab à Chicago, mais ces centres ne pourront satisfaire à l’ampleur des besoins. Aussi la mise en oeuvre d’une production Monte Carlo distribuée serait un apport essentiel pour permettre d’atteindre les objectifs fixés. Des centres de calcul comme celui de l'IN2P3 à Lyon sont partagés entre les différentes expériences de l'Institut et l'affectation de CPU pour des durées de l'ordre de la journée n'est guère envisageable. Ceci amène à rendre nécessaire l’utilisation de ressources PetaScale.


Climate :

To adress its increasing computational needs, climate modeling has to consider the whole supercomputing market offer, not only vector architectures but also scalar and massively parallel.


Today, petascale machines give us the opportunity to set up high resolution climate models. New physical phenomenons can be represented and forecast scores inproved, taking lower scale physics into account. Moreover, this accurate precision makes possible regional studies with global circulation models, for example on global warming impact and extreme events occurence like hurricanes, storms, heat waves ...


Our climate application mainly consists on an atmosphere model (ARPEGE, Météo-France) and an ocean model (NEMO-Paris6 University), communicating through a coupling software (OASIS, Cerfacs), which can be considered as a geo-specific improvement of the MPI communication library. Each model is itself MPI parallel (OpenMPI or MPICH).


The model setup, which has begun on Earth Simulator (JAMSTEC, Japan), is regularly updated on newer supercomputers (IBM Blue Gene/L, NEC SX9 ...). The present resolution reaches half a degree for ocean model and approximately one degree for atmosphere model (t159). Both components have 30 vertical levels. This configuration requires several hundreds of IBM BG/L cores. Several thousands, if using the 300 oceanic vertical levels configuration.


For statistical studies (ensemble runs or decadal predictions), climate modeling application could easily absorb petascale capacities and requires adaptations to take fully benefit of such computational power.

WP 4: Gestion des batchs Scheduler