Actes des journées. Journées scientifiques mésocentres et France Grilles

Dimension: px
Commencer à balayer dès la page:

Download "Actes des journées. Journées scientifiques mésocentres et France Grilles"

Transcription

1 Journées scientifiques mésocentres et France Grilles «supercalculateurs, grilles et clouds : des outils complémentaires pour la science» 1-3 oct Paris (France) Actes des journées version DRAFT septembre 2012

2 Table des matières Reproductive strategies, demography and mutational meltdown, D Abu awad [et al.]... 1 GINSENG (Global Initiative for Sentinel E-health Network on Grid), S Cipière [et al.]...3 MSDA / Vigrid : La grille de calcul EGI au service de l'analyse protéomique, C Carapito [et al.]... 7 Algorithmes évolutionnaires sur grille de calcul pour le calibrage de modéles géographiques, R Reuillon [et al.] Efficient fault monitoring with Collaborative Prediction, C Germain-renaud [et al.] années de mutualisation des ressources en calcul scientifique au PSMN de l'ens-lyon, H Gilquin.21 Synergie entre le mesocentre Grenoblois CIMENT et la grille europeene EGI pour la recherche de nouvelles particules dans l'experience ATLAS aupres du collisionneur LHC au CERN., C Biscarat [et al.]...23 A science-gateway workload archive application to the self-healing of workflow incidents, R Ferreira da silva [et al.]...27 SysFera-DS : Un portail d'accès unifié aux ressources des centres de calcul. Mise en application à EDF R&D, B Depardon [et al.] GeoQAIR : Quantification de l'apport d'une plateforme d'observations Géostationnaires pour la surveillance de la Qualité de l'air en Europe, M Eremenko [et al.]...35 Diffusion MRI Simulation with the Virtual Imaging Platform, L Wang [et al.] Hadoopizer : a cloud environment for bio-informatics data analysis, A Bretaudeau [et al.] Instance nationale et multi-communauté de DIRAC pour France Grilles, L Arrabito [et al.] Distributed Computing for Neurosciences: the N4U example, N Haitas [et al.]...53 Etude pangénomique des effets cis haplotypiques sur l'expression des gènes dans les monocytes humains, V Truong [et al.] Un service distribué sur le cloud pour l'execution de chaînes de traitements sur la grille, T Glatard RunMyCode, Y Stroppa Détection a posteriori de structure génétique des populations hiérarchisée, M Pauwels [et al.] metamatch: un algorithme pour l'assignation taxonomique en métagénomique, J Frigerio [et al.] Accélération du traitement de données avioniques : Hadoop@PireCloud, F Thiebolt [et al.] Common Operations of Environmental Research Infrastructures: the ENVRI project, Y Legre [et al.].. 81 Utilisation du Cloud StratusLab : tests de performance des clusters virtuels., C Cavet [et al.]...84 I

3 Reproductive strategies, demography and mutational meltdown Diala Abu Awad (1), Sophie Gallina(2), Cyrille Bonamy(3), Sylvain Billiard(4) (1) UMR-CNRS 8198 & Chaire de Modélisation Mathématique et Biodiversité (2) UMR-CNRS 8198 (3) CRI Université Lille 1 (4) sylvain.billiard@univ-lille1.fr, UMR-CNRS 8198 Overview: In spite of frequent transitions from strict outcrossing to self-fertilizing in plant populations [1, 2, 3] and the stringent conditions for the maintenance of strictly outcrossing reproductive systems [4, 5], there is a prevalence of outcrossing reproductive strategies in natural populations [6, 7]. It has been proposed that strictly outcrossing species have lower rates of extinction (as observed in phylogenies [1, 2]), due to differences in the accumulation of deleterious mutations leading to population extinction (mutational meltdown [8, 9]). Here we propose a theoretical model to study the joint effects of demography and genetics (the accumulation of deleterious mutations) on population viability for different rates of selffertilization. Enjeux scientifiques et besoin en calcul : Dans le cadre de l étude de l évolution et du maintient des populations végétales, la compréhension de l effet du système de reproduction sur la viabilité des populations est indispensable. La diversité des taux d autofécondation observée, et la prévalence des systèmes de reproduction favorisant l allo-fécondation, sont-elles dues à des différences dans les taux d extinction des populations en fonction de leur système de reproduction? Pour répondre à cette question nous utilisons une approche théorique en développant un modèle individu-centré, génétiquement et démographiquement explicite. On considère une population isolée d individus diploïdes, composés de 2 chromosomes, chaque chromosome a un nombre potentiellement infini de locus. Les générations sont discrètes et nonchevauchantes. On explore l effet de plusieurs paramètres génétiques, tels que le taux de mutation (U) par chromosome par génération, l effet des mutations délétères (leur coefficient de sélection s et leur dominance h), ainsi que le taux de recombinaison (L). Pour chaque simulation, ces paramètres sont considérés comme étant fixes, et on définit un taux d autofécondation (α) qui lui aussi reste fixe. Afin que le modèle explore une large gamme de paramètres, le programme est exécuté avec plus de 1500 jeux de paramètres, et utilise une approche stochastique nécessitant la génération de 1000 répétitions pour chaque jeu de paramètres. Le besoin de calcul est donc de l'ordre de 1,5 millions d'exécutions indépendantes du même programme. Le programme lui-même est assez rapide (quelques minutes à quelques heures), n'utilise pas de gros fichiers de données et ne nécessite pas de parallélisation. Développements, utilisation des infrastructures : Dans un premier temps, nous avons utilisé le cluster du CRI de Lille 1 [10], ce qui nous a permis d'explorer une partie des paramètres : 1,5 million d'analyses (environ heures de calcul) ont tournées au cours l'année Nous avons développé des scripts Perl pour la soumission des jobs, le contrôle de qualité et l'analyse des résultats. En 2012, pour la suite du projet, nous avons exploré d'autres questions scientifiques, pour lesquelles nous avons réalisé un premier essai sur la grille, via le logiciel Dirac [11] et la Vo biomed [12]. Pour l'ensemble des nouvelles analyses, représentant environ 6 ans de calcul, les résultats ont été disponibles en 5 jours. Outils, le cas échéant complémentarité des ressources, difficultés rencontrées : Les besoins informatiques pour notre projet concernant principalement des calculs paramétriques, le mesocentre régional nous a suggéré de commencer sur le cluster pour la phase de mise au point du modèle et des scripts de soumission, puis de passer sur la grille dans un second temps. Le rôle du mésocentre a été crucial pour le choix des infrastructures (HPC ou grille), le choix de la VO, l'accompagnement administratif pour les demandes d'entrée dans la grille, le choix des outils (glite [13] puis Dirac) et l'aide technique pour l'utilisation des ressources. Les difficultés techniques liées à l'utilisation de glite ont été dépassées grâce à l'utilisation de Dirac. Résultats scientifiques : Les résultats de cette étude théorique soutiennent l hypothèse que le système de reproduction a bien un effet sur la viabilité des populations dans le cadre de l accumulation des mutations délétères. Malgré une purge des mutations délétères plus efficace pour des taux d autofécondation élevés, les populations allo-fécondantes sont favorisées quand les mutations ont un effet faible sur la viabilité des individus, probablement dû à l évitement de la dépression de consanguinité [4]. 1/88

4 Figure 1 Résumé des résultats principaux. Viabilité des populations calculée à partir de 1000 simulations indépendantes pour différents taux d autofécondation (α), de mutation (U) et recombinaison (L), ainsi que différents coefficients de sélection (s) et de dominance (h). a) Distribution des tailles de population à l équilibre pour un jeu de paramètres. b) Temps pour l extinction en fonction du taux d autofécondation pour un jeu de paramètres. c), d), e), f) Moyenne conditionnelle de la taille de la population à l équilibre en fonction du taux d autofécondation. Perspectives : Effet d un perturbation démographique sur la viabilité Afin d établir si c est la taille de la population à l équilibre ou bien sa fitness qui détermine sa résistance face à une perturbation démographique, les simulations comprendront un goulot d étranglement (une baisse soudaine dans la taille de la population) et l évolution de ces populations sera suivie jusqu à l équilibre (extinction ou survie). Au vu du gain de performance avec l'utilisation de la grille, ces nouvelles analyses seront réalisées avec la VO biomed et l'outil Dirac. Références : (police Arial Narrow 12 points Gras) [1] E. E. Goldberg, J. R. Kohn, R. Lande, K. A. Robertson, S. A. Smith, and B. Igic. Species Selection Maintains Self-Incompatibility. Science, vol. 330, pp , OCT [2] D. Schoen, M. Johnston, A. LHeureux, and J. Marsolais. Evolutionary history of the mating system in Amsinckia (Boraginaceae). Evolution, vol. 51, pp , AUG [3] G. Stebbins, Flowering plants: evolution above the species level. Belknap Press, Belknap Press of Harvard University Press, [4] D. Charlesworth and B. Charlesworth. Inbreeding depression and its evolutionary consequences. Annual Review of Ecology and Systematics, vol. 18, pp , [5] E. Porcher and R. Lande, Loss of gametophytic self-incompatibility with evolution of inbreeding depression. Evolution, vol. 59, pp , JAN [6] J. Thomson and S. C. H. Barrett. Selection for outcrossing, sexual selection, and the evolution of dioecy in plants. American Naturalist, vol. 118, no. 3, pp , [7] P. Jarne and J. R. Auld. Animals mix it up too: The distribution of self-fertilization among hermaphroditic animals. Evolution, vol. 60, pp , SEP [8] R. LANDE. Risk of population extinction from _xation of new deleterious mutations. Evolution, vol. 48, pp , OCT [9] M. Lynch, J. Conery, and R. Burger. Mutational meltdowns in sexual populations. Evolution, vol. 49, pp , DEC [10] [11] A.Tsaregorodtsev, V.Hamar, M.Sapunov, T.Glatard, S.Camarasu-Pop, R.Ferreira da Silva, P.Girard, P.Gay. Infrastructure DIRAC pour les Communautés Pluridisciplinaires. Rencontres Scientifiques France Grilles 2011, Lyon, France [12] [13] 2/88

5 GINSENG, une infrastructure de grille au service de l e-santé et de l épidémiologie Sébastien Cipière (1,2,3), Sébastien Gaspard (5), David Manset (5), Jêrome Revillard (5), David Sarramia (1,2), Vincent Breton (1,2), David R.C. Hill( 1,2,4), Lydia Maigne (1,2) cipiere@clermont.in2p3.fr, sgaspard@maatg.fr, dmanset@maatg.fr, jrevillard@maatg.fr, sarramia@clermont.in2p3.fr, breton@clermont.in2p3.fr, david.hill@univ-bpclermont.fr, maigne@clermont.in2p3.fr. (1) Clermont Université, Université Blaise Pascal, LPC, BP 10448, F (2) CNRS/IN2P3, UMR6533, LPC, F (3) CNRS, UMR 6158, Université Blaise Pascal, LIMOS, F (4) ISIMA, Institut Supérieur d Informatique, de modélisation et de leurs Applications, BP 10125, F (5) MAAT France, GNUBILA Group, Argonay, F Overview: The GINSENG (Global Initiative for Sentinel E-health Network on Grid) project aims to implement a grid infrastructure for e- health and epidemiology in Auvergne. A distributed medical database is created upon a secure network for epidemiological studies. Our goal is to create a decentralized information system using grid technologies. The medical sites involved in the project are clustered around two themes: cancer monitoring and perinatal care. On each medical site a server which duplicates the medical database, is deployed with grid services. At the same time, full control of the information is kept by the organizations storing patients files. This solution allows for a high level of security, privacy, availability, and fault tolerance. Queries made on the distributed medical databases are made via a secure web portal. Public health authorities use this infrastructure for health monitoring, epidemiological studies and evaluation of specific medical practices. Mots clés: grille, bases de données, e-santé, épidémiologie, réseau de surveillance. Enjeux scientifiques, besoin en calcul, stockage et visualisation : Bases de données médicales distribuées Le projet GINSENG vise à mettre en réseau des bases de données médicales existantes et complémentaires dans le but de compléter les informations médicales manquantes à tout dossier de patient suivi dans le cadre d une pathologie. Les applications médicales choisies pour illustrer le principe de partage de la donnée médicale sont le suivi des cancers dans le cadre du dépistage organisé et le suivi des parturientes. Les bases de données médicales peuvent être de nature très hétérogène, elles comprennent des informations médicales textuelles ainsi que des imageries mais dans des domaines médicaux très différents comme par exemple une analyse de prélèvement sanguin (au format texte) qui pourra compléter une information issue de l imagerie comme la clarté nucale chez le fœtus potentiellement atteint de trisomie 21. Ces données médicales ne peuvent avoir un sens pour une analyse pertinente en santé publique si elles répondent à certains besoins des épidémiologistes : L information médicale doit être fiable, les données médicales doivent être chaînées de manière performante pour une compréhension globale de la pathologie médicale. L information doit être accessible en temps réel par tout utilisateur du réseau étant autorisé L information médicale doit être exhaustive ce qui implique qu elle puisse être complétée en temps réel également Pour répondre à ces enjeux, les bases médicales doivent être interconnectées efficacement en utilisant un format de données standardisé. Le choix du type de format standardisé doit être fait de manière à s adapter à toute structuration déjà établie de bases de données. Dans le cadre de ce projet, les données médicales restent pour la plupart textuelles avec néanmoins une utilisation d imagerie médicale peu volumineuse (mammographie ou échographie dont la taille n excède pas quelques mégaoctets.). Identification et chaînage des données médicales Le système a pour but de mettre en commun des bases de données provenant de divers sites médicaux. Il est alors primordial de s assurer de l identité des patients lors de l utilisation de leurs données médicales pour des études épidémiologiques. Il est possible par exemple, qu un patient consulte dans plusieurs sites médicaux, d autre part la probabilité qu un homonyme fréquente le même établissement de santé n est pas négligeable. Il est aussi envisageable que lors de l'enregistrement d un dossier dans le système d'information une erreur se soit produite. Ces trois différents cas doivent être correctement pris en charge par l infrastructure. En effet en aucun cas le système ne devra associer des patients distincts à une même identité. De la même façon qu'il est important que le système puisse associer deux dossiers provenant de deux services d'information différents au bon patient. Comme notre solution est développée sur le territoire français elle respecte les critères de la Commission Nationale de l Informatique et des Libertés (CNIL) qui garantit notamment le respect des conditions relatives à la gestion des bases de données intégrant des informations personnelles. Il s agit donc d utiliser des algorithmes d identification performants et rapides pour chaîner l information médicale d un même patient sur différents sites hospitaliers. 3/88

6 Sécurité À partir du moment où une information médicale est utilisée par une tierce personne ou bien transite via un réseau, les mécanismes de sécurité afférents doivent être très aboutis. La sécurité doit être présente à différents niveaux : au moment de l authentification d un utilisateur sur le réseau. Celui-ci doit être reconnu et ses droits d accès doivent être clairement notifiés. Lors du stockage des informations médicales dans les bases données. Ce stockage doit être réalisé de manière encryptée. Lors du transit de l information sur le réseau, le partage de la donnée médicale devra lui aussi être encrypté. Le réseau mis en place devra lui aussi être sécurisé et compartimenté pour chaque application du projet. Ces contraintes de sécurité doivent répondre également à toutes les contraintes légales françaises et européennes. Pour la France, la création de la «Loi relative à l informatique, aux fichiers et aux libertés du 6 janvier 1978». Cette loi encadre le traitement de l information en France, en stipulant que l informatique «Ne doit porter atteinte ni à l identité humaine, ni aux droits de l homme, ni à la vie privée, ni aux libertés individuelles ou publiques». Cette loi instaure aussi des droits aux citoyens, en leur donnant accès (opposition/rectification) aux données les concernant. Dans la lignée de la loi Informatique et Libertés, l Union Européenne s est dotée, en 1995 d un texte commun pour l ensemble des pays membres: la directive Européenne 95/46/CE. Cette loi est largement inspirée du texte français mais est moins restrictive : elle n impose pas une organisation de contrôle (indépendante) comme la CNIL. Accès et visualisation des données Une fois les données structurées et mises à disposition de manière sécurisée, il faut les rendre disponibles via une interface ergonomique et sécurisée. Les besoins des personnels médicaux, notamment en santé publique sont de 2 natures : Interroger les bases de données médicales de façon transparente et sécurisée. Visualiser l information médicale agglomérée par des graphiques ou bien par téléchargement de fichiers (au format csv) pour un post-traitement avec des logiciels d analyses statistiques comme SAS ou R (Bates et al., 2010). Dans la partie suivante, nous reprenons chacun des points dont les enjeux ont été détaillés pour en expliciter leur développement. Développements, utilisation des infrastructures : Bases de données médicales distribuées Chaque base de données médicale est dupliquée sur un serveur de grille appelé gateway. Les services présents sur cette gateway sont : Les services de grille standard glite BDII, LFC, WMS, LB et VOMS pour la glue du système. AMGA pour permettre la gestion de bases de données relationnelles distribués et hétérogènes. La gateway est la partie visible de chaque site, toutes les gateway sont interconnectées pour former un réseau. Le réseau ainsi créé constitue notre base de données distribuée. Dans un souci de sécurité maximale et de disponibilité des données patients, nous pouvons mettre en œuvre différents protocoles tel que la fragmentation de la base de données et une duplication de ces fragments. Ce qui nous permet de continuer d'avoir accès à la totalité des informations contenues dans la base de données bien que certains sites puissent être inaccessible. La structuration des données est réalisée sous le format FedEHR qui vise à fédérer les informations médicales sous une arborescence dans laquelle le patient est la racine de toute l information médicale basé sur les principes énoncé dans (Benson, 2010). Cette information est ensuite regroupée sous la forme d évènements médicaux, eux-mêmes agrégeant des variables cliniques. Toutes les bases de données médicales auxquelles nous avons pu avoir accès à ce jour ont été interprétées sous la structure FedEHR (notamment les bases de données gynécologiques, de dépistage des cancers et d anatomocytopathologie). Identification et chaînage des données médicales Pour répondre aux différentes problématiques liées à l'identification des patients nous avons retenu deux algorithmes : Jaro Winkler (Jaro, 1995) et Soundex (Quantin et al., 2004). L algorithme Jaro Winkler est basé sur l'analyse de chaînes de caractères. L algorithme Soundex est quant à lui un algorithme qui compare les données en se basant sur les phonèmes, ce qui permet de considérer «Philippe» et une version mal orthographiée de ce prénom telle que «filipe» comme étant similaire. Ces deux algorithmes auront à comparer les données des patients ; les informations que nous avons retenues sont le prénom, le nom, le sexe, la date de naissance, et l adresse. Pour améliorer la vitesse de traitement des algorithmes nous étudions actuellement des solutions basées sur la puissance des cartes graphiques GP GPU de type Fermi (Owens et al., 2008), qui pourront éventuellement être déployées sur le serveur ayant la charge de l'identification des patients. Sécurité En raison du caractère sensible des données manipulées, le projet GINSENG dispose d un réseau qui lui est propre. Ce réseau se situe pour sa plus grande partie au sein d un Virtual Private Network (VPN) (IPSEC) qui assure une sécurité 4/88

7 accrue des données. Ce VPN est créé au travers de l Internet et géré par des routeurs de marque Cisco. L accès au service s effectue par une page internet sur le site e-ginseng.org, pour qu une connexion s établisse l utilisateur doit disposer d une Carte de Professionnel de Santé (CPS). Cette carte est la clef d accès au Serveur Central d authentification (CAS). Le serveur central d authentification s appuie sur la technologie Virtual Organization Membership Service (VOMS), et la base de données distribuée utilise Arda Metadata catalogue (AMGA) (Koblitz, Santos, & Pose, 2007). Les données qui transitent sur le réseau sont encryptées bien qu elles transitent exclusivement par le VPN pour encore plus de sécurité. Accès et visualisation des données Un serveur Web héberge le site Internet du projet, qui est le point d'accès unique à l infrastructure. Le site Internet poursuit trois objectifs principaux, l'information, l'identification, et la gestion des requêtes épidémiologiques. Au travers d'une interface ergonomique et attractive, des informations statistiques sont rendues disponibles aux différentes catégories d utilisateurs. Les utilisateurs sont identifiés par un serveur Central Authentification Service (CAS) grâce à leur carte de professionnel de santé (CPS). Le serveur CAS permet une seule et unique authentification de l'utilisateur, tout en lui octroyant l'accès à tous les services, ainsi c'est le serveur CAS qui authentifie utilisateurs auprès du Virtual Organization Membership Service (VOMS) (Alfieri et al., 2005). En fonction de leur profession et de leur rôle au sein de l'organisation, les personnes authentifiées n'ont pas accès aux mêmes tableaux de bord. Une Virtual Organisation (VO) (Cummings, Finholt, Foster, Kesselman, & Lawrence, 2008) ou Organisation Virtuelle a été créée spécifiquement pour les besoins du projet. Elle a pour nom VO Sentinelle. Les requêtes effectuées sur les bases de données sont réalisées en langage SQL. Ces requêtes sont créées directement depuis le portail web e-ginseng.org et interprétées par toutes les gateways présentes sur les sites distants. Résultats scientifiques : Le projet GINSENG est en phase de développement. Les bases de données médicales utilisées pour tester les solutions techniques mentionnées ci-dessus sont pour l instant simulées en adoptant une structuration des données identiques aux bases de données médicales réelles. Identification et chaînage des données À ce jour, la phase de développement a permis de valider les algorithmes d identification Jaro Winkler et Soundex portées à la fois en langage C++ sur CPU (2.4 Ghz) et en langage CUDA sur GP-GPU de type Fermi (Tesla C2050). Il a été montré que l algorithme Jaro Winkler était plus rapide d un facteur 14 à la comparaison de 5 millions de noms et prénoms. Une prochaine étape est de tester les seuils d acceptance de comparaisons des 2 algorithmes en introduisant dans les bases de données simulées des erreurs comme l nsertion de prénoms composés, l inversion du nom et du prénom, l'ajout d'accents, le doublement d'une lettre, la suppression d'une lettre, l inversion de 2 lettres ou encore le remplacement d'une lettre. Car une étude menée par (Friedman & Sideli, 1992) a montré jusqu'à 27% d erreurs d identification de patients au sein de trois bases de données hospitalières de patients sur le même site. Les applications médicales Différents cas d études épidémiologiques ont fait l objet des premiers tests du réseau GINSENG. L intérêt est de montrer comment un système tel que GINSENG peut permettre d améliorer les études épidémiologiques en chaînant correctement les informations médicales provenant de sites médicaux différents. L étendue des potentialités de GINSENG est démontrée par des études à grande échelle concernant : L étude de l incidence d une pathologie o Exemple : Nombre de nouveaux cancers du sein sur la dernière année pour une ville donnée. L étude des facteurs de risques d une pathologie o Exemple : Recherche d éléments influençant la survenue de cancers. La validation d'une information de nature déclarative pour optimiser la prise de décisions médicales o Exemple : croisement des informations communiquées par la patientes et les BDD disponibles. L étude des pratiques médicales o Exemple : comparaison du taux de césariennes en fonction des maternités. Perspectives : Le projet est actuellement en phase de développement et de nouvelles solutions apparaissent régulièrement pour toujours plus sécuriser les données des patients et s assurer de leurs validités. Il sera envisagé d associer automatiquement les champs des bases métiers, aux champs FedHER de la base GINSENG au moyen d une ontologie comme le propose (Faucher, Bertrand, & Lafaye, 2008). À moyen terme les 11 plus importants hôpitaux auvergnats et les principaux cabinets d anatomocytopathologie seront équipés avec un serveur de type gateway pour prendre part au projet GINSENG. À long terme le projet permettra les l échange des données entre les divers partenaires, ainsi il sera envisageable d équiper des partenaires institutionnel tel que l InVS (Institut de Veille Sanitaire), qui pourra actualiser ses données quotidiennement. Les procédés que nous appliquons à la périnatalité et au suivi des cancers sont facilement transposables aux 5/88

8 problématiques qui pourraient se poser dans d autres domaines, ou secteurs d activité. Pour conclure un élargissement géographique à l échelle de la France est également envisagé. Références : Alfieri, R., Cecchini, R., Ciaschini, V., dell Agnello, L., Frohner, Á., Lorentey, K., & Spataro, F. (2005). From gridmap-file to VOMS: managing authorization in a Grid environment. Future Generation Computer Systems, 21(4), Elsevier. doi: /j.future Bates, D., Chambers, J., Dalgaard, P., Falcon, S., Gentleman, R., Hornik, K., Iacus, S., et al. (2010). The R Project. Power. Retrieved from Benson, T. (2010). The HL7 V3 RIM. Principles of Health Interoperability HL7 and SNOMED (pp. 1-20). Springer London. doi: / _7 Cummings, J., Finholt, T., Foster, I., Kesselman, C., & Lawrence, K. A. (2008). Beyond Being There: A Blueprint for Advancing the Design, Development, and Evaluation of Virtual Organizations. Technology (Vol. 3, p. 52). National Science Foundation. Retrieved from Faucher, C., Bertrand, F., & Lafaye, J.-Y. (2008). Génération d ontologie à partir d'un modèle métier UML annot. Revue des Nouvelles Technologies de linformation RNTI, E(12), Retrieved from /en/ Friedman, C., & Sideli, R. (1992). Tolerating spelling errors during patient validation. Computers and biomedical research an international journal, 25(5), Jaro, M. A. (1995). Probabilistic linkage of large public health data files. Statistics in Medicine, 14(5-7), doi: /sim Koblitz, B., Santos, N., & Pose, V. (2007). The AMGA Metadata Service. Journal of Grid Computing, 6(1), doi: /s Owens, J. D., Houston, M., Luebke, D., Green, S., Stone, J. E., & Phillips, J. C. (2008). GPU Computing. Proceedings of the IEEE, 96(5), ACM Press. doi: /jproc Quantin, C., Binquet, C., Bourquard, K., Allaert, F., Gouyon, B., Ferdynus, C., Pattisina, R., et al. (2004). Estimation de la valeur discriminante des traits d identification utilisés pour le rapprochement des données d un patient. Revue d Épidémiologie et de Santé Publique, 52(5), doi: /s (04) /88

9 MSDA / Vigrid : La grille de calcul EGI au service de l analyse protéomique Christine CARAPITO 1a, Jérôme PANSANEL 1b, Patrick GUTERL 1a, Alexandre BUREL 1a, Fabrice VARRIER 1a, Fabrice BERTILE 1a, Stéphane GENAUD 2, Alain VAN DORSSELAER 1a, Christelle ROY 1b 1 Institut Pluridisciplinaire Hubert Curien (IPHC), DSA a -DRS b, CNRS UMR7178, Université de Strasbourg, Strasbourg, France 2 Laboratoire de Sciences de l Image, de l Informatique et de la Télédétection (LSIIT), équipe ICPS, CNRS UMR 7005, Université de Strasbourg, Strasbourg, France Overview In line with genomics, proteomics has rapidly emerged as a promising field of research enabling the elucidation of numerous life sciences questions [1]. The tremendous progresses in mass spectrometry-based techniques over the last 20 years have led to the possibility to generate massive, highly accurate, qualitative and quantitative mass spectrometry data for very complex protein mixtures. The main bottleneck in proteomics research today resides in the interpretation of such massive data and new informatics/bioinformatics resources are strongly needed to support the emergence of the field [2]. The proteomists and computer scientists of the Hubert Curien Pluridisciplinary Institute (IPHC, Strasbourg, France) have interfaced open-source proteomics data interpretation tools on the EGI (European Grid Infrastructure) grid. Hence, by allowing higher throughput and larger scale proteomics projects to be solved, our MSDA pipeline (Mass Spectrometry Data Analysis, offers important time gain factors. It also opens new fields of applications that were previously unreachable due to a lack of computing resources. The originalities of the use of the EGI grid infrastructure for this pipeline are described in this article. Enjeux scientifiques, besoin en calcul, stockage et visualisation En parallèle de la génomique, la protéomique a émergé ces 20 dernières années comme un domaine de recherche essentiel pour élucider de nombreuses problématiques en Sciences de la Vie [1]. La spectrométrie de masse a joué un rôle fondamental dans le développement de l analyse protéomique. Les progrès instrumentaux ont conduit au développement d instruments générant des données de spectrométrie de masse de plus en plus volumineuses (du fait d une grande rapidité d acquisition des spectres de masse). Par ailleurs, la soumission des résultats d identification de protéines à partir de ces données est de plus en plus réglementée par les journaux du domaine qui recommandent l utilisation d algorithmes «opensource» et multiples si possible. Pourtant, les outils informatiques/bioinformatiques et les ressources de calcul disponibles constituent aujourd hui encore un verrou majeur dans le domaine de la protéomique [2]. Ainsi, afin de répondre au besoin croissant de puissance de calcul nécessaire à l interprétation des données de protéomique, la suite logicielle MSDA, bâtie sur des logiciels libres a été adaptée et améliorée (Vigrid) sur la grille de calcul. Développements, utilisation des infrastructures, outils, difficultés rencontrées I. MSDA : Interface utilisateurs Le portail d accès MSDA est une application web qui permet aux utilisateurs/protéomistes de réaliser l ensemble du workflow d interprétation des données de spectrométrie de masse allant de la génération des banques de données de séquences à l interprétation finale des spectres de masse. Son développement répond aux besoins suivants : - Offrir un portail d accès simplifié vers les applications, accessible à partir de tous types de postes de travail. - L adaptation d applications pour la grille nécessite de découper les données en entrée pour paralléliser les traitements en autant de jobs que possible, de façon à bénéficier au maximum des ressources offertes par la grille de calcul. L interprétation des données de spectrométrie est adaptée à un tel découpage car ce sont des tâches indépendantes dont les temps d exécution sont courts (quelques minutes). Par conséquent, il faut prendre en compte les temps d attente lors de la soumission de ces jobs afin d éviter qu ils ne soient supérieurs à leur temps d'exécution. - Permettre de transférer des fichiers volumineux (banques de données de séquences >100Mo et données de spectrométrie de masse à interpréter), ce qui est requis par les applications utilisées. - Assurer l aboutissement de l intégralité des calculs car un unique spectre de masse peut correspondre à la protéine d intérêt recherchée, ce qui a nécessité le développement d outils de supervision des tâches de calcul. L accès à ce portail, sécurisé via un système d authentification (identifiant/mot de passe), permet de soumettre et de superviser les différentes tâches soumises à des Computing Elements (CE) de la grille EGI. Chaque CE contrôle un ensemble de worker nodes (les unités de calcul) et est chargé de l ordonnancement des jobs sur ces nœuds. 7/88

10 II. Vigrid : Gestionnaire des requêtes de calcul par MSDA Nous avons développé Vigrid, un nouvel outil permettant d améliorer les soumissions de jobs faites à partir de MSDA. Cet outil se différencie de l approche glite [3] classique par deux aspects : - Un stockage intermédiaire des données sur des serveurs dédiés au stockage de la grille EGI : Storage Elements (SE). - Une stratégie de soumission optimisée en considérant les files d attente individuellement. Le logiciel Vigrid peut être utilisé dans n importe quel environnement et n est pas lié à la suite logicielle MSDA. C est un outil autonome qui peut être utilisé pour toute application faisant appel aux ressources des grilles de calcul. La figure 1 résume le schéma de l'utilisation de la grille EGI par le serveur MSDA et Vigrid. Les objets matérialisés en pointillés représentent les modules développés pour répondre aux besoins spécifiques de nos applications, en particulier la supervision. Figure 1 : Utilisation de la grille EGI par la plate-forme applicative MSDA/Vigrid. Les procédures de surveillance intégrée sont mises en évidence en pointillés. 1/ Transfert sur un Storage Element (SE) La politique de bon usage de la grille EGI recommande de limiter la taille de l Input Sandbox, c est-à-dire l ensemble des fichiers téléchargés vers le CE. Par conséquent, nous avons opté pour un mécanisme utilisant un SE comme espace de stockage intermédiaire. Ce mécanisme a deux avantages : - S'affranchir des limites imposées à la taille des Input Sandbox sur les CE ou les WMS (Workload Manager System). - Limiter les transferts de fichiers volumineux entre les différents CE et le serveur MSDA. A la fin de l exécution des tâches, les fichiers transférés sur le SE sont automatiquement effacés. 2/ Job Submission / Gestion des temps de latence L utilisation classique de glite conduit à soumettre les jobs à des WMS, qui sont des métaschedulers, qui accèdent ensuite aux CEs. Cette utilisation engendre des temps d attente (Status Waiting) qui peuvent atteindre jusqu à minutes, ce qui ne répond pas aux attentes des utilisateurs de ces applications spécifiques où des réponses rapides sont nécessaires pour la poursuite des expériences. L alternative est de soumettre directement les jobs à des CEs sélectionnés en évitant l'utilisation des WMS, en suivant une stratégie particulière de soumission. Pour optimiser le temps de latence, le logiciel JJS (Java Job Submission [4]) avait été utilisé dans un premier temps puis Vigrid, basé sur la distribution JSAGA (Implémentation en Java de l'api Simple API for Grid Applications [5]), a été développé en interne. Cet outil permet de soumettre des collections de jobs sur la grille et de sélectionner des ressources pertinentes. Il peut être déployé depuis n importe quel poste disposant d un certificat permettant d accéder à la VO, sans nécessiter de privilège administrateur ni interférer avec les logiciels d exploitation installés sur les grilles de calcul. Le ratio (temps d attente) / (durée d exécution du programme) devant être le plus faible possible, nous utilisons à la fois une liste des CE spécifiques, ainsi qu'un paramètre de soumission, TimeOutWait. Ce paramètre définit le temps maximal durant lequel un calcul peut rester en file d attente. Si ce temps est dépassé sur un CE, le calcul est annulé sur ce CE, qui est alors retiré de la liste des ressources disponibles. Le calcul est alors resoumis sur un CE ayant plus de ressources disponibles. Il est à noter que, contrairement à JJS, Vigrid considère chaque file de manière distincte plutôt que le site en entier, ce qui 8/88

11 permet d exclure une file de CE tout en conservant les autres files disponibles, le cas échéant, sur un CE donné. La liste des CEs est construite par rapport aux ressources disponibles, associées à la VO d appartenance (Biomed dans notre cas), publiées par l annuaire (TopBDII). Nous y ajoutons le résultat de l outil de supervision de Vigrid qui soumet périodiquement (par défaut toutes les heures) une commande pour évaluer le temps de réponse. Dans cet outil, trois états ont été définis : OK : la commande a été exécutée dans un temps inférieur au TimeOutWait (par défaut 10min). ERROR : le job a été rejeté par le CE. TIMEOUT : la durée TimeOutWait a été dépassée. Afin qu'un CE apparaisse dans la liste des ressources disponibles, il doit remplir les critères suivants : - Les attributs publiés par le TopBDII pour le CE doivent correspondre à nos prérequis. Par exemple, l'attribut GlueCEMaxCPUTime doit être supérieur à 120 minutes. - Le CE doit avoir obtenu un état «OK» lors de la dernière soumission. - Le CE doit avoir un rapport du nombre de succès par rapport au nombre de soumissions durant les N derniers jours supérieur à X. Fixer la valeur X à 0.75 par défaut semble être optimal puisque, d après l historique des mesures, il apparaît qu aucun site n est disponible en permanence en raison d aléas techniques. L outil de supervision de Vigrid permet donc de définir une liste ordonnée des files d attente des CE les plus réactives. Les soumissions de jobs se font en priorité sur les files d attente en haut de la liste. Les CE ou les files d attente ne répondant pas ne seront pas dans cette liste tant que l outil de supervision n aura pas obtenu de réponse de leur part. Les jobs sont soumis directement aux différents CEs et pris en charge par le gestionnaire de batch de chaque CE de manière banalisée. 3/ CE Monitoring / Gestion des tâches Pour répondre aux besoins de supervision et de gestion des tâches, Vigrid se base sur l approche utilisée par JJS et permet de suivre l état des jobs sur la base des états définis dans l'api («start», «submitted», «waiting», «running», «end», «aborted», «cancelled»). Les critères de gestion, schématisés dans la figure 2, sont les suivants : - Si le job est en état «start», «submit» ou «waiting» lorsque la valeur TimeOutWait est atteinte, le job est annulé et relancé sur un autre CE de la liste. - Si le job est en état «running», aucune action n est menée. - Si le job est en état «end», l ensemble des fichiers de sortie est téléchargé. - Si le job est en état «aborted» ou «cancelled», le job est relancé sur un autre CE et le CE non fonctionnel est retiré de la liste. Il est ainsi possible de piloter de manière dynamique l ensemble du processus de soumission des tâches de calcul. Figure 2 : Spécifications du système de gestion des tâches de Vigrid. 4/ Status Reporting Après chaque commande du fichier d exécution le code de retour doit être vérifié. En cas d erreur, le programme est interrompu. Pour affiner la supervision des programmes, chaque fichier d exécution (Executable Shell) soumis à un CE contient une fonction de reporting qui permet de renvoyer vers le portail les informations définies par le développeur. Ce mécanisme est basé sur un mode client/serveur ssh avec une sécurité renforcée sur un port non standard. Le serveur est configuré pour n accepter aucune commande interactive ni de session. L authentification est réalisée avec un couple clé privée/clé publique, la clé publique étant insérée dans le fichier d exécution de commandes. Périodiquement, les informations de reporting sont transmises vers le portail via la commande scp. Grâce à ce mécanisme, nous avons pu mettre en évidence certains problèmes de configuration de CE et mieux comprendre le comportement des CEs. 9/88

12 Résultats scientifiques La suite logicielle MSDA développée à l IPHC permet : - De créer, d extraire, de concaténer, de formater des banques de données de séquences protéiques, notamment à partir des banques de séquences publiques accessibles (NCBInr, UniProtKB, UniProtKB/SwissProt, ). - D interpréter à haut débit des données de spectrométrie de masse par recherches en banques de données (OMSSA : Open Mass Spectrometry Search Algorithm [6]). - D interpréter à haut débit des données de spectrométrie de masse acquises sur des organismes non séquencés par séquençage de novo suivi de recherches d homologies de séquences. - D extraire automatiquement l ensemble des annotations fonctionnelles disponibles sur les protéines identifiées. L utilisation de la grille pour ces applications permet des gains de temps considérables par rapport à l utilisation de serveurs locaux : - Un gain de temps net : Après optimisation des paramètres de lancement sur la grille et un découpage optimal des données en fonction du type d expérience mené, un set de données tests composé de 4 expériences typiques d analyses protéomiques par spectrométrie de masse a été utilisé pour évaluer les gains de temps atteints (Tableau 1). Par exemple, sans la grille, l expérience 4 n était que difficilement envisageable car elle nécessite la mobilisation du serveur du laboratoire durant 3 jours complets. Type d expérience de spectrométrie de masse Lancement sur un serveur local (h) Lancement sur la grille (h) Facteur de gain de temps 1.Spectrométrie de masse à haute résolution et spécificité enzymatique complète (65 fichiers d entrée: 62Mo) 0,3 0,2 1,5 2.Spectrométrie de masse à haute résolution et semi-spécificité enzymatique (65 fichiers d entrée: 62Mo) 5,8 0, Spectrométrie de masse à basse résolution et spécificité enzymatique complète (223 fichiers d entrée: 551 Mo) 3,6 0,7 5 4.Spectrométrie de masse à basse résolution et semi-spécificité enzymatique (223 fichiers d entrée: 551 Mo) 74,6 0,95 79 Tableau 1 : Facteurs de gains de temps obtenus pour le lancement de 4 types d expériences d interprétations de données de spectrométrie de masse sur un serveur local (4 CPUs / 8Go RAM / Scientific Linux bits) et sur la grille de calcul (GlueCEPolicyMaxCPUTime et GlueCEPolicyMaxWallTime:60min / 250 CPUs minimum / GlueCEStateStatus: Production). Ces valeurs sont des moyennes (environ 100 valeurs de temps mesurées par type d expérience) obtenues suite au lancement régulier de ces recherches sur une période de 3 mois. - Un gain de temps global : Les algorithmes d interprétation des données de spectrométrie de masse sont, en général, lancés sur un serveur dédié dans les laboratoires de protéomique. Ce système de ressource limitée impose une hiérarchisation des priorités des recherches. Avec la grille, l ensemble des utilisateurs peut lancer ses requêtes simultanément ce qui entraine un gain de temps global important, directement croissant et proportionnel au nombre d utilisateurs simultanés. Cette suite logicielle a été présentée à la communauté de protéomique lors du congrès annuel de la Société Française de Spectrométrie de Masse et d Analyse Protéomique (SMAP, Avignon, Septembre 2011). L application compte aujourd hui environ 31 utilisateurs internes et 43 utilisateurs externes à l IPHC. Conclusion & Perspectives Le logiciel Vigrid peut être intégré dans toute application souhaitant accéder à la grille de calcul et de bénéficier des spécifications suivantes : - Une gestion fine de l accès aux différentes files des CEs. - Une gestion permettant de différencier les états des jobs (Queuing/Waiting/Running/Abort) et de gérer dynamiquement ces états dans l application. Ce logiciel, associé à la librairie JSAGA, peut être déployé sur des ordinateurs dont le système d exploitation permet d exécuter des programmes en java, sans disposer de privilèges administrateur. Par ailleurs, l architecture de la suite logicielle MSDA est en cours d évolution. Un mécanisme de Web-service basé sur WSDL est en cours d implémentation et permettra de séparer la partie «Modèle» sur un serveur distinct et de diversifier l accès aux ressources. Pour la partie applicative, les développements se poursuivent également avec l implémentation de nouveaux modules (e.g. séquençage de novo, outils de quantification) dans MSDA. L utilisation de la grille a permis de répondre aux importants besoins de puissance de calcul non accessibles à ce jour dans les laboratoires de protéomique et ce type de développement contribuera certainement à briser le verrou majeur que constitue le manque de ressources informatiques / bioinformatiques dans le domaine de la protéomique. 10/88

13 Références [1] Bensimon A, et al. Annu Rev Biochem. 2012, 81: [2] Aebersold R. Nat Methods. 2009, 6(6): [3] glite - Lightweight Middleware for Grid Computing ( [4] JJS : Java Jobs Submission P.Calvat CCIN2P3 ( [5] JSAGA : A Java implementation developed at CCIN2P3 ( [6] Geer LY, et al. J Proteome Res. 2004, 3(5): /88

14 Algorithmes évolutionnaires sur grille de calcul pour le calibrage de modèles géographiques Romain Reuillon (1), Sebastien Rey (2), Clara Schmitt (3), Mathieu Leclaire (4), Denise Pumain (5) (1) Géographie cité, CNRS UMR 8504 (2) Géographie cité, CNRS UMR 8504 (3) Géographie cité, CNRS UMR 8504 (4) r, Géographie cité, CNRS UMR 8504 (5) Géographie cité, CNRS UMR 8504 Overview As dynamic geographic models integrate very large number of spatial interactions, large amount of computing is necessary for their simulation and calibration, in order to validate them. Here a new automated calibration procedure is experimented on the European computational grid EGI using evolutionnary algorithms. The application to the Simpoplocal model enables to reduce the computing time (one week) for managing about 7 millions runs for a preliminary validating step of the processes and parameters introduced in the model. Résumé Les modèles géographiques dynamiques mettant en jeu des interactions nombreuses entre des lieux exigent des masses importantes de calcul pour leur simulation et leur calibrage en vue de leur validation. Nous expérimentons ici une procédure de calibrage automatisé sur la grille de calcul européenne EGI fondée sur l emploi d algorithmes évolutionnaires. L application au modèle Simpoplocal permet en un temps assez court (une semaine) de traiter les quelque 7 millions d exécutions nécessaires à une première validation des processus et des paramètres introduits dans le modèle. Enjeux scientifiques, besoin en calcul, stockage et visualisation Les géographes modélisant les systèmes de villes s appuient sur l hypothèse que les interactions microgéographiques sont susceptibles de favoriser l émergence de dynamiques stylisées aux échelles macro-géographiques, qui constituent une des caractéristiques récurrentes, universelles, de ces systèmes complexes (Pumain 2007). L hétérogénéité et le grand nombre de scenarii d implémentation possibles pour représenter les processus en jeu, la description de dynamiques principalement individu-centrées, la non linéarité des interactions, la diversité des formes de relations spatiales et l importance du contexte historique (Pumain et al. 2006, Sanders 2005), sont tout autant de raisons qui amènent les géographes à utiliser régulièrement des modèles agents (Agent Based Models) comme support de réflexion et d expérimentation (Sanders 2007, Batty 2008). Tout l enjeu d une modélisation réussie en géographie est donc d arriver à réunir un faisceau de mécanismes dans le but de valider, ou plutôt d évaluer avec un intervalle de confiance élevé, un modèle pour une question donnée (Sargent 2010). Dans un contexte de travail en géographie quantitative souvent inter-disciplinaire (Archeomedes: Durand-Dastès et al. 1998, l ANR Transmondyn 1, l ERC Geodivercity 2 ), le choix des mécanismes et des règles du modèle passe par une phase de dialogue et d échange caractéristique de la co-évolution entre les concepts des thématiciens experts du domaine et des modélisateurs pilotant la construction d un modèle. La construction d un modèle sur ces bases interdisciplinaires engage bien souvent les modélisateurs dans une démarche de construction itérative et incrémentale. C est sur cette base mouvante que nos outils et protocoles doivent se construire pour répondre au mieux à ces besoins d expérimentation de nature itérative (Louail, Pumain, 2009). La réussite de cette construction est liée à la possibilité d évaluation et au savoir expert qui doit être mobilisé à toutes les étapes de la construction et de l expérimentation du modèle, lorsqu il s agit de confronter les résultats d une instance d un modèle par rapport à la question théorique qui l a motivé. Ce processus d évaluation doit être rendu plus systématique qu il n était possible de le faire lors des premières applications de modèles multi-agents en géographie (Bura et al., 1996, Poix et Michelin, 2001). Nommée face validity selon un des principes fondateurs de la VV&T (Verification Validation and Testing) (Osman Balci 1998, Sargent 2005), cette étape permet de concrétiser les semblants d évaluation ou les recherches de comportements attendus raisonnables par la définition d indicateurs objectifs émanant des thématiciens experts du domaine (Sharma et al. 2006). C est à la lecture de ces résultats, et au regard de la question initialement posée que les mécanismes doivent être pré-calibrés pour éviter une divergence incrémentale et grandissante entre l'implémentation (vérification interne) et les questions initialement posées (validation externe). Le calibrage, ou du moins le pré-calibrage est un des nombreux problèmes inverses que se posent les modélisateurs (Bourgine et al., 2008). Un problème inverse est une question sur les sorties d un modèle qui vise à comprendre quelles 1http:// 2http://geodivercity.parisgeo.cnrs.fr/blog/ 12/88

15 valeurs des paramètres d entrée permettent d obtenir certaines dynamiques ou certains motifs. Quelle que soit la proximité attendue entre les résultats du modèle et des observations, que les modèles soient guidés par les données ou plus théoriques ou simplifiés, il est important de pouvoir déterminer si l ensemble des paramètres estimés par le modèle à l issue d une simulation, en fonction des règles qui y ont été intégrées, correspond à une solution unique ou très probable, ou bien s il ne s agit que d un minimum local que la dynamique a moins de chances de rencontrer dans le paysage vallonné de l espace des phases des états du modèle. Cette phase de calibrage est généralement menée à bien par essai-erreur, et a conduit par exemple à se contenter d une centaine de simulations lors de l expérimentation sur différents systèmes de villes d une version consolidée du modèle SIMPOP2 (Bretagnolle, Pumain, 2010) ; cependant, la non-linéarité des interactions et le fait que certains paramètres n aient pas d équivalence empirique, associés au fait que chaque nouvel incrément dans l avancement du modèle puisse venir perturber l ancienne dynamique, rendent alors très difficile et fastidieuse une calibration manuelle du modèle. Il est ainsi crucial d automatiser le processus de calibrage et de substituer de manière temporaire l expertise humaine sur le modèle par une expertise automatisée, opérant à la manière d un filtre qui requiert une traduction quantitative de l évaluation experte. Il est donc nécessaire d envisager des méthodes et outils qui permettent de penser cette automatisation dans ce cadre original qu est la calibration systématique de nos modèles. Outils L automatisation du calibrage nécessite dans un premier temps la définition d un certain nombre d objectifs résumant la qualité d un jeu de paramètres par rapport à des résultats attendus du modèle. Ces fonctions objectifs sont calculées à partir de l exécution d un ensemble de réplications d une simulation utilisant un même jeu de paramètres (le modèle étant stochastique, chaque réplication correspond à un flux de nombres aléatoires indépendant de ceux des autres réplications). Ensuite, le processus de calibrage sélectionne les meilleurs jeux de paramètres d après les valeurs atteintes pour ces objectifs. Pour calibrer des modèles multi-agents l évaluation répétée des objectifs constitue donc une charge de calcul très importante qui ne peut être menée à bien que sur des environnements de calcul haute performance. Du fait du nombre des paramètres et du caractère généralement continu de leur domaine de variation, l habituel parameter sweeping distribué sur grille (Casanova, 2003), ou plan complet, est généralement inefficace pour calibrer les systèmes en haute dimension. D une part, le nombre d expériences à mener pour ce type de plan croit de manière exponentielle avec le nombre de paramètres à l étude. D autre part, un plan complet génère une grande quantité de données qu il faut traiter et visualiser a posteriori. Le problème de recherche de motif dans l espace des dynamiques du modèle est ainsi remplacé par un problème de recherche de motif dans une base de données. Le post-traitement de cette masse de données est cependant long et fastidieux. L impossibilité de recourir à ces méthodes exhaustives nous pousse ici à envisager le calibrage non plus comme une recherche de comportement satisfaisant parmi l ensemble des possibles, mais bien comme objectif qu il nous faut atteindre, moyennant un questionnement inverse : Existe-t-il une combinaisons de paramètres permettant de remplir les objectifs fixés? L observation a posteriori devient question a priori, puisque les objectifs préalablement définis pour faire état d un résultat deviennent les nouveaux guides permettant d alimenter une ou plusieurs méthodes d optimisation issues de la métaheuristique. Toutes les méthodes d'optimisation permettant une recherche guidée dans un espace inconnu doivent jongler entre deux buts contradictoires, en réduisant le temps de recherche des solutions optimales tout en parcourant au mieux l'ensemble de l'espace porteur à la fois de bonnes et de mauvaises solutions. Pour notre problème, nous avons choisi d utiliser les algorithmes génétiques (Holland, 1975) du fait qu il proposent une recherche globale dans l espace des paramètres et présentent des aspects naturellement parallèles qui peuvent être exploités sur grille de calcul. On trouve des exemples récents de calibrage automatisé de modèles qui soulignent l intérêt d une recherche globale dans l espace des paramètres (via des algorithmes évolutionnaires) plutôt que par des approches de recherche locales (Solomatine, 1999). De plus, l emploi récent d algorithmes évolutionnaires pour calibrer des modèles ABM (Rogers et Tessin 2004) en géographie (Heppenstall et al. 2007) a prouvé toute l utilité de ces techniques pour le calibrage de modèle. L utilisation de méthodes de recherche globale pour le calibrage de modèles est généralement extrêmement coûteuse en calcul. Même si des méthodes ont été développées pour réduire le nombre d évaluation du modèle dans certains cas (Liu et al., 2005) l utilisation d algorithmes évolutionnaires pour le calibrage de modèles de systèmes complexes requiert l utilisation de parallélisme massif. Développements, utilisation des infrastructures L utilisation d algorithmes génétiques pour le calibrage d un modèle multi-agents (et plus particulièrement multi-agents stochastiques) demande une charge de calcul très importante qui ne peut être fournie que par des environnements de calcul massivement distribués. 13/88

16 Afin d illustrer les méthodes expliquées ici, prenons l exemple du modèle SimpopLocal. Celui-ci étudie la structuration hiérarchique de peuplements au moment de l émergence des villes, quelque 3000 ans après celle de l agriculture (Bairoch, 1985) en simulant la dynamique de croissance de systèmes de peuplement sous contrainte environnementale. A visée clairement exploratoire, ce modèle cherche d abord à reproduire et à étudier dans des conditions particulières (fortes contraintes environnementales) un phénomène très bien décrit dans la littérature par un fait stylisé : l organisation hiérarchique de systèmes de peuplements sous forme d une distribution Rank-Size à partir des interactions spatiales (échanges d information notamment) entre les unités de peuplement (Berry, 1964). Dans la mesure où le processus a pris des formes diverses selon les régions du monde, bien documentés par les travaux des archéologues (Marcus et Sabloff, 2008), le modèle Simpoplocal a été conçu comme une simplification abstraite, générique, de l émergence des villes, à partir d un très petit nombre de règles (5) et de paramètres (une dizaine). On ne dispose d aucune information historique permettant d attribuer des valeurs numériques à au moins 7 de ces paramètres. Dans son implémentation la plus efficace une exécution de Simpoplocal dure 40s sur un processeur moderne. Le modèle étant stochastique, les variables de sorties sont aléatoires et l évaluation d un jeu de paramètres donné nécessite a minima 30 réplications indépendantes de ce modèle et donc l utilisation de 1200s de temps processeur. Il est donc impératif de paralléliser les évaluations pour calibrer ce modèle. De nombreuses méthodes ont été développées dans le but de paralléliser efficacement les algorithmes génétiques (Alba et al., 1999). Les algorithmes à état stationnaire ou steady state (Syswerda, 1991) présentent une alternatives aux algorithmes générationnels en prenant en compte les solutions à mesure qu elles sont évaluées. Ils présentent à la fois de meilleurs propriétés de convergence (Durillo, 2008 ) et son caractère asynchrone lui procure une robustesse naturelle face aux hétérogénéités en temps de calcul des environnements de type grille. Pour le problème de calibrage de SimpopLocal qui vise à satisfaire 3 objectifs, nous avons utilisé l'algorithme génétique NSGA II steady state (Syswerda, 1991, Deb, 2001). Cet algorithme a été implémenté au sein de la bibliothèque MGO 3 et distribué sur grille grâce à OpenMOLE (Reuillon, 2010) 4, deux logiciels libre écrit en scala. Résultats scientifiques L application de cette démarche a donné des résultats probants pour répondre au problème de calibrage de SimpopLocal. Avec sept paramètres dont la valeur ne pouvait être estimée de façon empirique, la recherche d un jeu de paramètres qui puisse satisfaire les trois objectifs de simulation (une forme de distribution de tailles de villes, une taille maximale et la durée nécessaire pour les structurer) s avérait fastidieuse. La première expérience ayant abouti à des propositions de jeux de paramètres candidats au calibrage a nécessité la simulation de près de 6,9 millions d exécutions du modèle, ce qui représente plus de 10 années consécutives de calcul. Ces chiffres impressionnants illustrent bien la difficulté de cette tâche de calibrage devant l absence de connaissances a priori des comportements du modèle. On se demande si par le moyen d une recherche manuelle, le même résultat aurait pu être trouvé avec moins d expériences et autant de certitude... le test n en vaut certainement pas le coût! Par retro-projection des solutions de l espace des objectifs dans l espace des paramètres, cette procédure d automatisation du calibrage du modèle a permis de trouver un ensemble de jeux de paramètres possibles amenant de bons résultats en termes de reproduction des faits stylisés, et donc contribuant à valider la qualité du modèle. Une évaluation multi-objectif ne conduit pas forcément à la sélection d un jeu de paramètres unique et peut mener à un ensemble de candidats possibles au calibrage : chaque jeu de paramètres sélectionné par la procédure est un compromis pour chaque objectif. L ensemble de ces candidats forment un front de Pareto (cette expression recouvre un ensemble de solutions dans lequel aucun des éléments n est meilleur que les autres sur l ensemble de ces objectifs). Néanmoins, parmi les jeux de paramètres proposés par la procédure, certains sont moins satisfaisants que les autres du point de vue des thématiciens. L introduction de connaissance experte a posteriori dans cette procédure a permis d affiner la fonction d évaluation et d opérer une discrimination bénéfique dans les jeux de paramètres candidats. Ces techniques de calibrage automatique sont maintenant utilisées de manière systématique pour réaliser des séries d expérimentations qui cherchent à préciser et à valider l implication dans la dynamique du modèle de chaque nouveau mécanisme implémenté. Ces expérimentations visent à tester la qualité des solutions possibles en fonctions de l activation / désactivation de mécanismes dans le modèle. On dispose dès lors d un moyen de tester non seulement la validité des valeurs des paramètres, mais aussi d évaluer la plausibilité des règles introduites dans le modèle. 3https://forge.iscpif.fr/projects/mgo 4http:// 14/88

17 Conclusion et perspectives Le calibrage automatique fondé sur un algorithme évolutionnaire multi-objectifs nous a permis d utiliser des environnements de calcul haute performance et notamment la grille de calcul pour produire un ensemble de solutions compromis. Ces solutions ont ensuite été analysées avant d être exploitées afin de comprendre comment des dynamiques interagissent pour simuler la hiérarchisation progressive d un système de villes. Cependant, dans le cas de Simpoplocal, un état vers lequel l algorithme a convergé est atteint au bout d une semaine en temps effectif de calcul sur la grille, temps nécessaire pour mener à bien les 10 années / CPU de simulation. Pour utiliser cette méthode de manière routinière lors de la conception itérative de modèles de systèmes complexes, il est certainement possible d améliorer encore le temps global de calcul en utilisant des algorithmes évolutionnaires plus récents que NSGA 2 comme MO-CMA-ES (Igel et al., 2007) qui pourraient s'avérer plus efficaces ou encore en développant des stratégies de distributions de populations sur un modèle d îlots (Whitley, 1997) qui sont particulièrement efficaces dans un contexte de calcul distribué. Remerciements Ce travail est financé par l'erc Geodivercity, l'agence de l'environnement et la Maitrise de l'energie (ADEME), le réseau Réseau de Recherche sur le Développement Soutenable (R²DS), l'institut des Systèmes Complexes Paris Ile-De-France (ISC-PIF) Références Alba, E. & Troya, J. M. A survey of parallel distributed genetic algorithms. Complex. 4, (1999). Balci, O. Verification, Validation, and Testing. Handbook of Simulation (2007). Batty, M. Fifty Years of Urban modelling : Macro-Statics to Macro-Dynamics. The Dynamics of Complex Urban Systems 1 21 (2008). Berry, B. J. L. Cities as systems within systems of cities. Papers in Regional Science 13, (1964). Bourgine, P. et al. French Roadmap for complex Systems arxiv: (2009). Bretagnolle, A. & Pumain, D. Simulating Urban Networks through Multiscalar Space-Time Dynamics: Europe and the United States, 17th-20th Centuries. Urban Studies 47, (2010). Bura, S., Guérin-Pace, F., Mathian, H., Pumain, D. & Sanders, L. Multiagent Systems and the Dynamics of a Settlement System. Geographical Analysis 28, (1996). Casanova, H. & Berman, F. Parameter Sweeps on the Grid with APST. Grid Computing (2003). Deb, K., Agrawal, S., Pratap, A. & Meyarivan, T. A Fast Elitist Non-dominated Sorting Genetic Algorithm for Multi-objective Optimization: NSGA-II. Parallel Problem Solving from Nature PPSN VI 1917, Durand-Dastès, F. et al. Archaeomedes : Des oppida aux métropoles. (Anthropos: Paris, 1998). Durillo, J. J., Nebro, A. J., Luna, F. & Alba, E. A study of master-slave approaches to parallelize NSGA-II. IEEE International Symposium on Parallel and Distributed Processing, IPDPS (2008).doi: /IPDPS Heppenstall, A., Andrew, E. & Birkin, M. Using Hybrid Agent-Based Systems to Model Spatially-Influenced Retail Markets. (2006). Holland, J. Adaptation in Natural and Artificial Systems. (University of Michigan Press: 1975). Igel, C., Hansen, N. & Roth, S. Covariance Matrix Adaptation for Multi-objective Optimization. Evolutionary Computation 15, 1 28 (2007). Liu, Y. & Ye, W.-J. Time Consuming Numerical Model Calibration Using Genetic Algorithm (GA), 1-Nearest Neighbor (1NN) Classifier and Principal Component Analysis (PCA). Engineering in Medicine and Biology Society, IEEE-EMBS th Annual International Conference of the (2005).doi: /IEMBS Louail, T. & Pumain, D. Interaction des ontologies informatique et géographique pour simuler les dynamiques multiscalaires. Rochebrune 09 : Ontologie et dynamique des systèmes complexes, perspectives interdisciplinaires (2009). Marcus, J. & Sabloff, J. A. The ancient city: New perspectives on urbanism in the old and new world. 2005, (School for Advanced Research: Santa Fe, 2008). Michelin, Y. & Poix, C. Simulation paysagère : un modèle multi-agents pour prendre en compte les relations sociales. Cybergeo : European Journal of Geography (2000).doi: /cybergeo.2242 Pumain, D., Bretagnolle, A. & Daudé, E. From theory to modelling : urban systems as complex systems. Cybergeo : European Journal of Geography (2006). Pumain, D. Une approche de la complexité en géographie. Géocarrefour 78, (2007). Reuillon, R. et al. Declarative task delegation in OpenMOLE International Conference on High Performance Computing and Simulation (HPCS) (2010). Rogers, A. & von Tessin, P. Multi-Objective Calibration For Agent-Based Models. (2004). Sanders, L. Intelligence artificielle et agents collectifs : le modèle EUROSIM. (2005). Sanders, L. Objets géographiques et simulation agent, entre thématique et méthodologie. Revue Internationale de Géomatique 17, (2007). 15/88

18 Sargent, R. G. Verification and validation of simulation models. Simulation Conference (WSC), Proceedings of the 2010 Winter (2010).doi: /WSC Sargent, R. G. Verification and validation of simulation models. Proceedings of the 37th conference on Winter simulation (2005). Solomatine, D. P., Dibike, Y. B. & Kukuric, N. Automatic calibration of groundwater models using global optimization techniques. Hydrological Sciences Journal 44, (1999). Syswerda, G. A study of reproduction in generational and steady-state genetic algorithms. Foundations of Genetic Algorithms (1991). Vimal Sharma, Swayne David, David Lam & William Schertzer Auto-Calibration of Hydrological Models Using High Performance Computing. Whitley, D., Rana, S. & Heckendorn, R. B. Island Model Genetic Algorithms and Linearly Separable Problems. In Evolutionary Computing, AISB Workshop (1997). 16/88

19 Efficient fault monitoring with Collaborative Prediction Dawei Feng (1), Cécile Germain-Renaud (1), Tristan Glatard (2) (1) Laboratoire de Recherche en Informatique, CNRS Université Paris-Sud (2) CREATIS, CNRS INSERM Université Lyon 1 INSA Lyon Overview Isolating users from the inevitable faults in large distributed systems is critical to Quality of Experience. We formulate the problem of probe selection for fault prediction based on end-to-end probing as a Collaborative Prediction (CP) problem. On an extensive experimental dataset from the EGI grid, the combination of the Maximum Margin Matrix Factorization approach to CP and Active Learning shows excellent performance, reducing the number of probes typically by 80% to 90%. Problem statement The recent crash of the Amazon Cloud [1] highlighted the importance of timely discovery of failures in large-scale distributed systems: a local, limited error may result in a global catastrophe. Thus a significant part of the software infrastructure of large scale distributed systems, whether grids or clouds, collects information (monitoring) that will be exploited to discover (knowledge) if, where, and when the system is faulty. This paper addresses the knowledge-building step in the context of end-to-end probing as the class of monitoring techniques. In the end-to-end probing approach, a probe is a program launched from a reliable entry point (probe station), which tests the availability of the components on its path. The only observables are the outcomes of the probes, which are binary: success or failure. For instance, a ping command would test the overall software stacks and network connectivity from the probe station to the target computer. This abstract summarizes our approach to minimize the number of probes for a given discovery performance target. Minimizing the number of probes can be addressed along three avenues: fault prediction, detection and diagnosis. In all cases, the system under consideration is a set of hardware and software components, featuring some dependencies e.g. a service certainly depends on the hardware it is running on, and possibly of other services. The obvious advantage of detection and diagnosis is that they provide an explanation of the failure, by exhibiting culprits. On the other hand, they strongly rely on a-priori knowledge, namely which components are required for a probe to succeed. For massively distributed systems, where Lamport s famous definition A distributed system is one in which the failure of a computer you didn t even know existed can render your own computer unusable applies, assuming such knowledge might be hazardous in principle. Instead, this paper focuses on fault prediction. In this case, the overall infrastructure is a black box, with no a-priori knowledge of its structure. Methods A. Motivation for Collaborative Prediction The motivating application comes from operations management in the European Grid Initiative (EGI), and specifically the Biomed Virtual Organization. Biomed has access to 256 Computing Elements (CEs) and 121 Storage Elements (SEs). CEs are shares of computing resources, implemented as queues of each site manager (e.g. PBS), and SEs are shares of storage resources; the formal definition is part of the Glue Information model [3]. The probes test the availability of all relations between its endpoints, namely Computing Elements (CEs) and Storage Elements (SEs). Testing the availability of all CE-SE pairs is one of the most challenging issues encountered daily by monitoring operators. Brute force, that is periodically launching a fully distributed all-pairs availability test, for a total of tests, multiplied by the number of capacities to test at each run, is both intrusive and useless: human operators cannot handle so many results; in practice, only a few issues are reported, with questionable selection criteria. With our method, a massive reduction of the number of tests provides nearly similar availability evaluation performance, creating opportunities for better frequency/intrusiveness trade-off and selection of reported incidents. In this context, fault prediction can be considered as a case for Collaborative Prediction (CP). CP is originally a technique for predicting unknown ratings of products for a particular user, based on observed data from other users and products. The success of CP relies on the hypothesis of a factorial model: hidden and partially shared factors affect the ratings. In our case, two nodes (CE or SE) may share several hidden factors - e.g. location, with the associated network connectivity issues, or use of a particular instance of any middleware service (e.g. brokering, authentication), such that the availability of the CE-SE relation may be affected similarly. B. Selection and prediction Minimizing the number of probes encompasses two issues: probe selection, i.e. which subset of the (CE,SE) pairs to actually test; and predicting the availability of all pairs from the outcome of these probes. 17/88

20 Probe selection. We consider two probe selection strategies. - Static-Uniform. The probes are selected uniformly at random. In this setting, the prediction step has no influence over the choice of the probes. - Active Probing. With Active Probing (Algorithm 1), the set of probes is constructed dynamically, with an initial set of probes selected for instance by the Static-Uniform method, and run through the system to get basic information; then, additional probes are selected and launched with the goal of maximizing some measure of information; here we used the min-margin heuristic [12], which chooses the probe where the uncertainty of the classification result is maximal, and has been demonstrated to be efficient for CP problems [13]. Collaborative Prediction with MMMF Algorithm 1: Generic active probing algorithm This section sketches Maximum Margin Matrix Factorization as proposed by Srebro et al. in [2]. CP is formalized as a matrix completion problem: if Y is an observed (sparse) matrix, the CP problem is to find a full, real-valued, matrix X of the same size that approximates Y, i.e. that minimizes the discrepancy between X and Y, without any external information. Assuming a linear factor model, where k hidden factors define the user preference through a linear combination of them, X is constrained to be of rank k. However, bounding k to small values (low-rank approximation) does not lead to feasible optimization problems for a partially observed matrix and for the binary setting. The key insight in MMMF is to replace the bounded rank constraint with bounding the trace norm of X, under the constraint of no (hard-margin), or small (soft-margin), discrepancy. Experimental setting Different capabilities have to be tested; in the following, we consider three of them: probe srm-ls tests the list ability from a CE to a SE, probe lcg-cr tests the read ability from a CE to a SE, and probe lcg-cp tests the write ability alike. Thus, each CE works as a probe station, launching probes to test the functionalities between itself and each SE. For the Biomed grid a whole set of testing transactions were launched each day for each of the three probe classes. After nearly two months running, information for 51 validated days were collected. The probes themselves are glite jobs, run by a regular Biomed user. Some of them fail (rejection) in the sense that glite is not able to complete the job, denoting that some job management services may be down or misconfigured (e.g. authentication, brokering etc.). In the following, we consider only the accepted probes, i.e. those which run to completion, reporting success or failure; this approach amounts to consider that the data access capacities are independent from job management. This is a reasonable hypothesis in a glite infrastructure because file transfers involved in job management use dedicated storage space independent from the one tested by our probes. Figure 1 illustrates the structure for lcg-cr on day , where rows represent CEs and columns stand for SEs. Each entry is the probe result between the corresponding CE and SE. Black columns correspond to sustained SE downtimes while black lines are CE failures leading to complete inability to communicate with any SE (e.g. network downtime or configuration issue). These are usually easily detected and reported by human operators with only a few incident reports. The scattered points, however, correspond to local or transient issues, which are very difficult to handle due to the amount of incident reports independently generated. It is thus worth assessing the performance of the methods when sustained systematic errors are eliminated. To do that, we designed a second set of experiments, with curated matrices as the reference fault structure. A curated matrix is a new original matrix, where the lines and columns with only failed entries (black ones in figure 2) have been removed prior to analysis. Experimental results A. Static-Uniform. Figure 2 shows the accuracy (ratio of correctly predicted entries over total number of entries) for five randomly selected days. An excellent performance can be reached with a tiny fraction of the original probes, typically 5%. The baseline, a random guess following the distribution of the sample set, is plotted for comparison purpose, but can be computed a-priori. Figure 3 is the classical visualization of the confusion matrix in the ROC space for all the 51 days at 90% deletion rate (keeping 10% of the probes). Perfect prediction would yield a point in the upper left corner at coordinate (0,1), representing 100% sensitivity (no false negatives) and 100% specificity (no false positives). 18/88

21 Figure 2. Accuracy for the Static-Uniform selection (five days) Figure 3. ROC values for for the Static-Uniform selection (all 51 days) The srm-ls dataset shows nearly perfect prediction performance, being mostly very close to (0,1); lcg-cp and lcg-cr are vastly better than a random guess, which lies on the diagonal line (note the range of the axes, which cover only the part of the ROC space where the results belong, thus the diagonal line is not visible on the plot). The other classical indicators also show excellent performance: Area Under ROC Curve (AUC) as well as MCC (Matthews Correlation Coefficient) are close to 1. The problem becomes much more difficult when the systematic faults are excluded, thus taking the curated matrices as inputs. The prediction accuracy remains excellent; however, as the number of failed entries left in the curated matrices is much less than in the un-curated ones, e.g. the fraction of failed entries on srm-ls, drops from 45.37% to 2.25%, accuracy is not meaningful: predicting all entries as negative would give a similar result. The strategy to tackle this issue is Active Probing. B. Active probing. In this experiment, we compare the Active Probing strategy with the Static one at equal probing cost: first, a Static- Uniform method is applied, in order to get the reference information, then more probes are selected with the min- margin heuristic for Active Probing, while for the Static- Uniform method, the same number of probes are selected uniformly at random. (a) Sensitivity (b) Precision Figure 4. Performance comparison for Static-uniform and Active Probing, curated srm-ls for the five benchmark days. Active Probing does improve accuracy over Static-Uniform. However, as explained in the previous section, the quality of failure prediction is the most important goal in this context. Figure 4 compares two relevant indicators: sensitivity (the probability of detecting an actual failure), and precision (the closer to 1, the smaller the risk of a false alarm). They are detailed for the initial probe fraction equal to 5%, then adding probes by step of 5% fractions. The results as given for a total of 10% and 15% probes. The first important result is that Active Probing always outperforms Static-Uniform. In fact, the performance of the Static-Uniform strategy is bad, except for (day 5). The performance bears some relation with the failure rate of the benchmark (table I): larger failure rates in the original curated matrix help uncovering the structure of the faults, even at quite low levels: with 4% failure rate, the benchmark exhibits acceptable performance when keeping only 5% of the probes and the Static-Uniform strategy. However, the failure rate does not tell the full story: days 2 and 4 have the same low one (1%), but the performance on day 4 is much better than on day 2. The likely explanation is that faults at day 2 do not present much correlation, while faults day 4 derive from a small number of shared causes. The second result is that Active Probing is quite efficient. We have a good chance of predicting the actual failure, except on day 2, while the false alarm rate remains negligible. A third strategy, omitted here for brevity, harnesses active probing with a differentiated cost policy [6, 7], where the false positives are more penalized. In all case, except day 2, sensitivity increases by 10-20%, while precision remains almost unharmed. A complete description and more experimental results can be found in [8]. Related Work Collaborative Prediction associated with end-to-end probing, with the components structure considered as a black box, 19/88

22 participates in the general Quality of Experience approach [9]. More precisely, an important ingredient separating QoE from QoS is binary (possibly extended to discrete) classification. Most work in this area is devoted to network- based services (e.g. among many others [10]). Before QoE became a popular keyword, Rish and Tesauro [5] explored the combination of MMMF and Active probing for the selection of good servers in various distributed and P2P systems. Our work combines the goal of proposing fault-free services to the user exemplified in [4], [11], and the CP approach of [5]. Z. Zheng and M.R. Lyu propose explicit users collaboration for estimating failure probabilities [11]; while their end-to-end framework is related to ours, the goal is more in line with QoS (estimating the full distribution of probability instead of binary classification), and the correlation amongst users or services is modeled by ad hoc methods. To our knowledge, this work is the first one to exemplify MMMF on fault prediction. Perspectives The Achille s heel of large-scale production grids and clouds is reliability. Quality of Experience at reasonable human cost requires extracting the hidden information from monitoring data whose intrusiveness should be limited. Collaborative Prediction is one of the promising and scalable strategies that can address this goal. This paper demonstrates its effectiveness on a large experimental dataset. Further work will consider two avenues. Exploiting the resulting knowledge the hidden causes uncovered by CP towards diagnosis might be easier with alternative matrix factorization techniques; specifically Bi-LDA [12] provides a quantified model of latent factors, which, like LDA, could be exploited for interpretation [13] more easily than MMMF, but suffers from lower performance. The second avenue targets improving prediction by separating transient failures from more permanent non- systematic ones, with temporal models inspired from the hierarchical Hidden Markov Models approach of text mining. Références [1] H. Blodget. (2011, April) Amazon s cloud crash disaster permanently destroyed many customers data. Business Insider. [Online]. Available: [2] N. Srebro, J. D. M. Rennie, and T. S. Jaakola, Maximum-margin matrix factorization, in Advances in Neural Information Processing Systems 17, 2005, pp [3] S. Andreozzi and al., Glue Schema Specification, V.2.0, Tech. Rep., [4] I. Rish and al., Adaptive diagnosis in distributed systems, IEEE Trans. Neural Networks, vol. 16, no. 5, pp , [5] I. Rish and G. Tesauro, Estimating end-to-end performance by collaborative prediction with active sampling, in Integrated Network Management, 2007, pp [6] K. Morik, P. Brockhausen, and T. Joachims, Combining statistical learning with a knowledge-based approach - a case study in intensive care monitoring, in 16th Int. Conf. on Machine Learning, 1999, pp [7] Y. Lin, G. Wahba, H. Zhang, and Y. Lee, Statistical properties and adaptive tuning of support vector machines, Machine Learning, vol. 48, pp , September [8] D. Feng, C. Germain-Renaud and T. Glatard. Distributed Monitoring with Collaborative Prediction. In 12th IEEE International Symposium on Cluster, Cloud and Grid Computing (CCGrid'12) 2012, pp [9] H. Rifai, S. Mohammed, and A. Mellouk, A brief synthesis of QoS- QoE methodologies, in 10th Int. Symp. on Programming and Systems, 2011, pp [10] H. Tran and A. Mellouk, QoE model driven for network services, in Wired/Wireless Internet Communications, ser. LNCS, 2010, vol. 6074, pp [11] Z.ZhengandM.R.Lyu, Collaborative reliability prediction of service- oriented systems, in 32nd ACM/IEEE Int. Conf. on Software Engineering, [12] I. Porteous, E. Bart, and M. Welling, Multi-hdp: a non parametric bayesian model for tensor factorization, in 23rd Conf. on Artificial Intelligence, 2008, pp [13] T. L. Griffiths and M. Steyvers, Finding scientific topics, Procs of the National Academy of Sciences, vol. 101, pp , /88

23 5 années de mutualisation des ressources en calcul scientifique au PSMN de l ENS-Lyon. Hervé GILQUIN (1) (1) Herve.Gilquin@ens-lyon.fr, UMPA UMR 5669 CNRS ENS-Lyon. Overview: (police Arial Narrow 12 points Gras) The PSMN (Pôle Scientifique de Modélisation Numérique) was founded in Since 2007, the PSMN has supported the pooling of resources dedicated to scientific computing at ENS-Lyon. After a brief history describing the evolution of the PSMN structure since its founding in 1993, I will develop its evolution since I will focus specifically on the description of the highlights of its functioning (involvement of all participants and flexibility) illustrated by some examples of research and publications this operation has made possible. I will conclude with the objectives to achieve in order to sustain the structure. Enjeux scientifiques, besoin en ressources dédiées au calcul scientifique. L ENS-Lyon a été crée en 1987, l établissement c est développé rapidement, hébergeant un nombre croissant de laboratoires de recherche. D autre part, l importance grandissante de la modélisation ainsi que l utilisation de plus en plus importante du calcul scientifique dans les différents laboratoires de l ENS-Lyon ont entrainé une croissance très rapide de l utilisation des ressources informatiques dédiées au calcul scientifique. Regroupant à l origine (1993) les moyens dédiés au calcul scientifique de trois laboratoires CNRS de l ENS-Lyon, le PSMN (Pôle Scientifique de Modélisation Numérique) a vu son périmètre s accroître en suivant le développement de l établissement, il regroupe maintenant une quinzaine de laboratoires représentant de l ordre de 150 utilisateurs.qui ont accès à environ 3000 cœurs de calcul (soit de l ordre de 25 M heures de calcul). Je présenterai cette évolution en insistant sur les points clés. Développements, utilisation des infrastructures. Crée en 1993, le PSMN a connu trois étapes dans son développement : - de 1994 à 2002, c est d abord une structure pluri-formation financée via les plan quadriennaux successifs. - de 2002 à 2010 il fait partie de la Structure Fédérative de Recherche FLCHP (Fédération Lyonnaise de Calcul Haute Performance) qui regroupe trois établissements Lyonnais (Ecole Centrale de Lyon, Ecole Normale Supérieure de Lyon et Université Lyon I). - depuis 2011 (jusqu à 2015), il fait partie de la Structure Fédérative de Recherche FLMSN (Fédération Lyonnaise de Modélisation et Sciences Numériques). Parallèlement à cette évolution certains laboratoires de l ENS ont continué à acquérir des serveurs qu ils hébergeaient et administraient eux-mêmes. Dès 2007, la direction de l ENS-Lyon a confié au PSMN la mission de mutualiser tous les équipements dédiés au calcul scientifique et s est engagée à en assurer l hébergement et le fonctionnement dans une salle informatique dont la première phase de l aménagement a été terminée finn La présentation décrira donc les différentes étapes en développant plus particulièrement la période Fonctionnement de la mutualisation. Le fonctionnement et la mutualisation s appuient sur une implication constante des différentes équipes et laboratoires membres du PSMN. Le fonctionnement est facilité par l organisation; toutes les équipes et les laboratoires désignent leur représentant au bureau des utilisateurs. Ce représentant est la personne habilitée à donner les autorisations d ouverture de compte. D autre part, ces mêmes représentants informent le responsable de la structure PSMN des différents financements acquis et/ou demandés afin d harmoniser les acquisitions de matériel. Enfin, le responsable du PSMN travaille en étroite collaboration avec les services financiers et la direction de la recherche. La présentation détaillera ces différents aspects. Exemples de résultats scientifiques. Quelques exemples de recherches ou publications qui ont été rendues possibles ou facilitées par le fonctionnement et la mutualisation tels qu ils sont appliqués au PSMN seront présentés et développés. Pérennisation de la structure. Jusqu à fin du plan quinquennal , l objectif est la pérennisation de la structure ; cela impose de réaliser la seconde phase de l aménagement de la salle hébergeant les serveurs (augmentation de la puissance électrique et de la puissance de refroidissement et de répondre aux demandes croissantes en stockage liées à des banques de données mises ensuite à la disposition de communautés d utilisateurs. D autre part une réflexion s est engagée et doit être approfondie à propos de la mise en commun des compétences des divers personnels non chercheurs impliqués dans le calcul scientifique dans l établissement. J évoquerai ces objectifs à atteindre. 21/88

24 Références Sylvain Joubaud, James Munroe, Philippe Odier and Thierry Dauxois, Experimental parametric subharmonic instability in stratified fluids; Phys. Fluids 24, (2012). Laurène Meyniel-Schicklin, Benoît de Chassey, Patrice André and Vincent Lotteau, Viruses and interactomes in translation; Molecular and Cellular Proteomics (2012). Slimane Laref, Yan Li, Marie-Laure Bocquet, Françoise Delbecq, Philippe Sautet and David Loffreda, "Nature of adhesion of condensed organic films on platinum by first-principles simulations", Physical Chemistry Chemical Physics, vol. 13 (2011) p Chevillard Laurent; Lévêque Emmanuel; Taddia Francesco; et al., " Local and nonlocal pressure Hessian effects in real and synthetic fluid turbulence ", PHYSICS OF FLUIDS Volume: 23 Issue: 9 Article Number: DOI: / Published: SEP M. Harb, F. Rabilloud, D. Simon, "Optical response of silver nanoclusters complexed with aromatic thiol molecules: a timedependent density-functional study ", J. Phys. B: At. Mol. Opt. Phys., 44, (2011). 22/88

25 Synergie entre le mésocentre grenoblois CIMENT et la grille européenne EGI pour la recherche de nouvelles particules dans l'expérience ATLAS auprès du collisionneur LHC au CERN Catherine Biscarat(1), Quentin Buat(2), Jan Stark(3) (1) LPSC, CNRS-IN2P3, UJF, INP (2) LPSC, CNRS-IN2P3, UJF, INP (3) LPSC, CNRS-IN2P3, UJF, INP Overview: We describe the synergy between the production grids of CIMENT (a multidisciplinary mesocentre in Grenoble) and WLCG (the LHC computing grid) for the analysis of data recorded by the ATLAS experiment at the LHC collider. The LHC collider at CERN (Geneva, Switzerland) is the leading facility for research at the high energy frontier. The main goal of this facility are the search for a subatomic particle called the Higgs boson and the search for any hints of new phenomena beyond the Standard Model of particle physics. The observation of the Higgs boson has been announced earlier this month by ATLAS and CMS, the two general-purpose experiments operating at the LHC. Researchers at LPSC in Grenoble are leading the search for one particular type of new phenomena in the ATLAS experiment, namely the search for additional spatial dimensions which would manifest themselves via the production of a particle called graviton in LHC collisions. Given the rich multitude of physics studies proceeding in parallel in the ATLAS collaboration, one of the limiting factors in the timely analysis of ATLAS data is the availability of computing resources. This limitation becomes problematic in the months that precede the international conferences where major results are released. The sharing of resources between different scientific fields, like the one discussed in this article, constitutes a valuable synergy, because the spikes in need for computing resources are uncorrelated in time between different fields. The result of our collaboration between fields manifest themselves in the timely publication of the LHC results that are eagerly awaited both by the particle physics community and by the general public. Enjeux scientifiques, besoin en calcul, stockage et visualisation : Ces quatre dernières décennies, les physiciens des particules ont établi le Modèle Standard de la physique des particules (MS) qui décrit l'ensemble des particules élémentaires constituant la matière et leurs interactions. Ce modèle incorpore trois des quatre interactions fondamentales connues : électromagnétisme, interaction faible et interaction forte. La gravitation n'est pas incluse car nous n'avons pas trouvé la clef pour décrire ensemble, dans une théorie cohérente, les aspects quantiques qui concernent les constituants élémentaires de la matière et la relativité générale qui concerne la gravitation. Depuis son élaboration, le MS n'a jamais été mis en défaut par les expériences. Ses prédictions ont été vérifiées par les observations expérimentales avec une extrême précision et il a aussi prédit l'existence, aujourd'hui avérée, de plusieurs particules telles que le boson de Higgs dont la découverte a été annoncée très récemment (le 4 juillet 2012) par ATLAS et CMS, les expériences généralistes installées auprès du collisionneur le plus énergétique du monde, le LHC (Large Hadron Collider) à Genève en Suisse. Malgré son pouvoir prédictif, le MS souffre d'insuffisances et d'aspects ad hoc non naturels (comme la nécessité d'ajuster finement la valeur de certains paramètres du modèle). Ceci matérialise notre manque de compréhension détaillée de la nature de ces interactions à des énergies élevées, dont le MS décrirait le cas limite aux énergies relativement basses que nous avons explorées jusqu'à présent. Plusieurs théories plus fondamentales et plus complètes, supposant l'existence de nouvelles particules ou de nouvelles symétries, ont été proposées pour résoudre ces problèmes. Le LHC est l'instrument qui a été construit principalement pour mettre en évidence le boson de Higgs. Le deuxième pan de son programme de physique est la production de nouveaux phénomènes dont l'observation étaierait l'une ou l'autre de ces théories. L'analyse des données des expériences LHC, et en l'occurrence de ATLAS, nécessite une grande puissance de calcul. En effet jusqu'en 2011 une luminosité intégrée de 4,9 fb -1 a été accumulée par ATLAS, correspondant à 1,6 milliards d'événements, soit 1,0 PB de données brutes (à la sortie du détecteur). Les événements bruts sont tout d'abord «reconstruits» pour dégager les objets physiques créés dans la collision (les particules élémentaires) à partir des informations données par les canaux de lecture du détecteur ATLAS. Les objets reconstruits sont alors analysés et comparés à des simulations pour chercher des déviations du jeu de données de ATLAS par rapport à un modèle donné. Cette dernière étape, appelée «analyse finale», est opérée par un grand nombre de physiciens qui sont organisés en groupes de quelques personnes travaillant indépendamment les uns des autres. Pour assurer la grande puissance de calcul demandée par les expériences LHC (sans parler du stockage ici), la communauté LHC s'est organisée afin de fournir une grille de production fiable et puissante. Celle-ci est appelée WLCG. Elle s'appuie sur la grille européenne EGI (European Grid Initiative) qui regroupe environ 150 sites dans le monde entier et dont le LPSC (Laboratoire de Physique Subatomique et de Cosmologie) de Grenoble est un nœud de niveau secondaire : il accueille les simulations du détecteur et les analyses finales des physiciens. Les sites WLCG ont eu un grand succès dans la préparation des données (reconstruction et simulation) pour les analyses 23/88

26 finales présentées aux dernières conférences, et notamment pour la recherche du boson de Higgs dont l'observation a été annoncée il y a quelques jours à l'une des conférences les plus réputées de notre domaine, ICHEP (International Conference on High Energy Physics). Toutefois, toutes les analyses sont en compétition pour obtenir de la puissance de calcul en période de conférence. La grille de production CIMENT [1] soutient des thématiques de recherche différentes de la physique des particules et n'observe pas des pics d'utilisation corrélés. Ainsi, l'utilisation de la grille de production CIMENT pour les analyses finales de physiciens des particules du LPSC constitue une véritable synergie entre le site de productions LPSC de EGI et de la grille de production de CIMENT dont la collaboration a débuté en 2010 [2]. Développements, utilisation des infrastructures : Les infrastructures de CIMENT et de WLCG sont différentes et disjointes : le stockage : irods pour CIMENT et DPM pour WLCG au LPSC; l'intergiciel : cigri pour CIMENT et glite pour WLCG. Ces différences constituent une difficulté pour passer d'une grille à l'autre. De plus, dans les sites LCG, toutes les applications et les paquets utilisés par les expériences sont installés automatiquement (de façon globale) alors que les nœuds de CIMENT sont «nus» en ce qui concerne les applications de physique des particules. Le portage des applications en est bien-sûr complexifié. Nous avons dû écrire des programmes spécifiques pour permettre le déploiement automatique et l'exécution des applications de physique des particules sur des machines nues. Concrètement nous utilisons ces programmes pour exécuter et chaîner des applications telles que : ROOT [3] : la boîte à outil standard pour l'analyse des données scientifiques en physique des particules abondamment utilisée dans notre discipline ; LHAPDF [4] : la bibliothèque standard de description de la structure du proton et d'autres projectiles communément utilisés en physique des particules ; DIPHOX [5] : générateur précis d'état final en une paire de photons ; sur CIMENT. Aussi, une spécificité des études de physique avec l'outil DIPHOX est la quantification des incertitudes systématiques. Cela consiste à exécuter de nombreuses fois DIPHOX en faisant varier des valeurs des paramètres théoriques. Ainsi nous avons conçu et écrit des applications pour encapsuler ces différentes exécutions. Outils, le cas échéant complémentarité des ressources, difficultés rencontrées : La physique des particules est une discipline qui foisonne d'activités et de résultats dont chaque brique doit être confrontée aux autres pour offrir un panorama complet des constituants élémentaires de la matière et de leurs interactions. Plus précisément, les résultats d'expériences indépendantes auprès de collisionneurs complémentaires (en terme d'énergie ou bien de nature des faisceaux) doivent être combinés pour en extraire des conclusions sur les lois fondamentales de la nature. En effet, le programme de physique du LHC est en lui-même extrêmement riche mais il existe aussi plusieurs autres collisionneurs qui ont fourni des résultats qui sont nécessaires pour interpréter les données du LHC. Citons par exemple les résultats des collisionneurs HERA à Hambourg en Allemagne et Tevatron à Chicago aux Etats-Unis sur la structure du proton. En effet les protons sont les projectiles utilisés dans le collisionneur LHC et la connaissance de leur structure est un pré-requis pour interpréter les données du LHC. Ou citons encore les résultats sur la masse du quark top et celle du boson W obtenus au Tevatron qui nous permettent de mettre à jour la nature du boson découvert récemment au LHC. Ainsi, chaque année, la communauté de physique des particules organise deux grandes conférences internationales pendant lesquelles les résultats récents sont présentés à la communauté et confrontés aux résultats obtenus par ailleurs. Ces grandes séries de conférence sont : «Les rencontres de Moriond» qui ont lieu chaque hiver, et «ICHEP» (International Conference on High Energy Physics) et «Lepton-Photon» qui se déroulent un été sur deux en alternance. Ces rendez-vous rythment la vie des expériences et la publication des résultats. Ils sont très importants, notamment pour les étudiants de doctorat qui peuvent alors mettre en valeur le produit de leur recherche. Chaque expérience LHC participe à ces conférences et présente les analyses faites sur la plus grande quantité possible de données, c'est-à-dire en incluant les données les plus récentes. De ce fait, les ressources de calcul sont particulièrement sollicitées les mois qui précédent ces conférences. Or, les sites WLCG sont les mêmes pour toutes les expériences et aussi pour les activités de production (comme celles de simulation) et les activités d'analyse, rendant aux utilisateurs l'accès aux ressources plus délicates dans ces périodes. 24/88

27 La consolidation du site du LPSC avec la grille CIMENT nous permet naturellement de contourner ce phénomène de «bouchon» aux périodes de conférences car les disciplines qui historiquement sont supportées par CIMENT sont dissociées en temps des grands rendez-vous de la physique des particules. Les analyses menées au LPSC sur la recherche de RS gravitons dans ATLAS ont ainsi bénéficié de la disponibilité et la grande réactivité de la grille CIMENT. Résultats scientifiques : Comme nous l'avons mentionné plus haut, un des buts majeurs en physique des particules ces dernières décennies a été d'explorer des extensions du MS afin de comprendre les aspects ad hocs et non naturels de cette théorie. Les théories audelà du MS postulent pour la plupart l'existence de nouvelles particules, de nouvelles dimensions spatiales ou bien de nouvelles symétries. Dans le modèle de Randall-Sundrum (RS) [6] qui nous intéresse ici, une géométrie spatiale avec une dimension supplémentaire est supposée, la cinquième dimension étant compactifiée avec la longueur r c. Une des manifestations de cette théorie serait l'existence de gravitons excités qui pourraient être produits au LHC. La théorie peut être décrite avec deux paramètres : la masse du graviton le plus léger (m G) et le couplage aux champs du MS ( k / M Pl où M Pl est directement proportionnelle à l'échelle de Planck M Pl ). Au LPSC, les physiciens sont leaders dans la recherche de gravitons dans le canal di-photon : G γ γ. Ce canal est particulièrement intéressant car il représente une signature expérimentale très claire dans un collisionneur hadronique comme le LHC. Aussi, il offre une excellente résolution en masse et comporte peu de bruit de fond physique tout en comptant un taux d'embranchement relativement grand (deux fois supérieur aux autres canaux de désintégrations individuels en lepton chargés G l l ). Des simulations Monte Carlo sont utilisées pour interpréter les données. Le générateur d'événements de paire de photons DIPHOX est utilisé afin de corriger le spectre en masse diphoton des événements complets générés avec le générateur d'événements standard PYTHIA [7]. Cette méthode permet de prendre en compte des effets fins tels que des corrections à l'ordre supérieur dans les graphes de production de paires de photon et des processus de fragmentation. Pour cette analyse, l'ensemble des données de ATLAS collectées jusqu'en 2011 sont exploitées. La figure 1 montre que les données et les prédictions du MS sont en bon accord sur toute la plage de masse observée. En l'absence de signal, des limites sur la production de gravitons dans le modèle RS sont déterminées. Elles sont présentées sur la figure 1. Fig. 1 : Gauche : Masse invariante de la paire de photon observée, avec la prédiction des contributions du MS et, superposés, les signaux RS qui seraient attendus pour divers modèles. Droite : Limites observée et attendue à 95% de degré de confiance sur la section efficace de production de gravitons dans le modèle de RS se désintégrant en une paire de photons (courbes les plus horizontales) en fonction de la masse du graviton ; et sections efficaces de production théoriques pour différentes valeurs du paramètre de la théorie k / (courbes obliques). M Pl Ces résultats ont été montrés par la Collaboration ATLAS pour la première fois à la conférence ICHEP de cette année en juillet 2012 [8]. Une publication du même résultat dans un journal réputé dans la discipline est en cours de finalisation. Perspectives : Les résultats obtenus lors de ce premier portage d'applications de physique des hautes énergies (ROOT, DIPHOX,...) sur CIMENT ont été essentiels pour le travail de nos équipes de recherche. Nous disposons maintenant de toute une architecture pour de futures études systématiques pour la recherche de dimensions spatiales supplémentaires dans l'expérience ATLAS. Celle-ci a été utilisée par nos équipes pour faire des vérifications dans l'analyse des données /88

28 Pour la version de l'analyse en cours d'élaboration qui comprend les données de ATLAS prises en 2012, les ressources de CIMENT sont utilisées de façon routinière et font partie intégrante des résultats officiels de la Collaboration ATLAS. Fort de cette expérience avec DIPHOX, nous élargissons le spectre des calculs sur CIMENT en portant un autre maillon de la chaîne de cette analyse : l'interprétation statistique des données. Cette application est appelée BAT [9] et elle n'est actuellement pas disponible sur CIMENT. La mutualisation des ressources de calcul entre différentes disciplines, scientifiques comme c'est le cas ici, constitue une véritable synergie car les différentes disciplines utilisent les ressources de façon dé-corélée en temps, absorbant ainsi mieux les pics d'utilisation. Le résultat direct de cette collaboration se manifeste par l'élaboration plus rapide des résultats du LHC tant attendus à la fois par la communauté de physique des particules et par le grand public. Références : [1] [2] C. Biscarat et B. Bzeznik, «Collaboration des grilles de production grenobloises CIMENT et LPSC - Développement, ouverture à de nouvelles communautés d'utilisateurs et impacts scientifiques», Rencontres Scientifiques France-Grilles, Lyon (2011) ; [3] [4] M.R. Whalley, D. Bourilkov, R.C. Group, contributed to HERA and the LHC: A Workshop on the Implications of HERA and LHC Physics (Startup Meeting, CERN, March 2004; Midterm Meeting, CERN, October 2004), Hamburg, Germany, Mar 2005 ; e-print Archive: hep-ph/ ; [5] T. Binoth, J.P. Guillet, E. Pilon et M. Werlen, «A full next-to-leading order study of direct photon pair production in hadronic collisions», Eur. Phys. J. C16 (2000), ; e-print Archive : hep-ph/ [6] L. Randall et R. Sundrum, Phys. Rev. Lett. 83, 3370 (1999). [7] T. Sjöstrand et al., Comput. Phys. Commun. 135, 238 (2001). [8] «Search for resonances in lepton pairs and photon pairs with the ATLAS detector», presenté par X. AnduAga Del Popolo le 7 juillet 2012 dans la session parallèle «BSM - Non-SUSY Exotics» de la conférence ICHEP, Melbourne, Australie. [9] A. Caldwell, D. Kollar, K. Kröninger, «BAT The bayesian analysis Toolkit», Computer Physics Communications 180 (2009) (ScienceDirect) [arxiv: ], 26/88

29 A science-gateway workload archive application to the self-healing of workflow incidents Rafael Ferreira da Silva (1), Tristan Glatard (2), Frédéric Desprez (3) (1) (2) Université de Lyon, CNRS, INSERM, CREATIS, Villeurbanne, France (3) INRIA, Université de Lyon, LIP, ENS Lyon, Lyon, France Overview Information about the execution of distributed workload is important for studies in computer science and engineering, but workloads acquired at the infrastructure-level reputably lack information about users and application-level middleware. Meanwhile, workloads acquired at science-gateway level contain detailed information about users, pilot jobs, task sub-steps, bag of tasks and workflow executions. In this work, we present a science-gateway archive, we illustrate its possibilities on a few case studies, and we use it for the autonomic handling of workflow incidents. Introduction, challenges Execution logs are widely used for research on distributed systems, to validate assumptions, model computational activity, and evaluate methods in simulation or in experimental conditions. Some of these logs are collected by workload archives, such as the Grid Workloads Archive [1], and made available online to the community. However, as they are gathered at infrastructure level, they lack critical information about dependencies among tasks, about task sub-steps, about artifacts introduced by application-level scheduling, and about users. On the other hand, information acquired at science-gateway level adds value to several case studies related to user accounting, pilot jobs, fine-grained task analysis, bag of tasks, and workflows. In this work, we present our science-gateway archive extracted from the Virtual Imaging Platform (VIP) [2] and available in the Grid Observatory [3], we illustrate its possibilities on a few case studies, and we show how it can be used for the autonomic handling of workflow incidents. A science-gateway archive Our science-gateway archive is based on the workload of the Virtual Imaging Platform. VIP is an open web platform for medical simulation. Users authenticate to a web portal with login and password, and are then mapped to X.509 robot credentials. Applications deployed in VIP are described as workflows executed using MOTEUR workflow engine [4]. Resource provisioning and task scheduling is provided by DIRAC [5] using pilot-jobs. Tasks are executed on the biomed virtual organization of the European Grid Infrastructure (EGI) 1. Our science-gateway archive model adopts the schema on Figure 1. Task contains information such as final status, exit code, timestamps of internal steps, application and workflow activity name. Each task is associated to a Pilot Job. Workflow Execution gathers all the activities and tasks of a workflow execution, Site connects pilots and tasks to a grid site, and File provides the list of files associated to a task and workflow execution. In this work we focus on Task, Workflow Execution and Pilot Job. Figure 1. Science-gateway archive model. The science-gateway archive is extracted from VIP. Task, Site and Workflow Execution information are acquired from databases populated by the workflow engine at runtime. File and Pilot Job information are extracted from the parsing of task standard output and error files. Studies presented in this work are based on the workload of VIP from January 2011 to April It consists of 2, /88

30 workflows executions, 112 users, 339,545 pilot jobs, 680,988 tasks where 338,989 are completed tasks, 138,480 error tasks, 105,488 aborted tasks, 15,576 aborted task replicas, 48,293 stalled tasks and 34,162 submitted or queued tasks. Stalled tasks are tasks which lost communication with the pilot manager, e.g. because they were killed by computing sites due to quota violation. Traces used in this work are available to the community in the Grid Observatory 2. Pilot jobs are increasingly used to improve scheduling and reliability on production grids. This type of workload, however, is difficult to analyze from infrastructure traces as a single pilot can wrap several tasks and users without informing the infrastructure. Figure 2 shows the number of tasks and users per pilot presented in the archive. Most pilots (83%) execute only 1 task due to walltime limits or other discards, which represents 62% of the task set. On workloads acquired at infrastructure level, about 38% of the task set would be misunderstood. The distribution of users per pilots has a similar decrease: 95% of the pilots execute tasks of a single user. Figure 2. Histogram of tasks per pilot (left) and users per pilot (right). Figure 3 compares the number of submitted jobs, consumed CPU time, and consumed wall-clock time obtained by the EGI infrastructure and by VIP. The number of jobs reported by EGI is almost twice as important as in VIP. This huge discrepancy is explained by the fact that many pilot jobs do not register to the pilot system due to some technical issues, or do not execute any task due to the absence of workload, or execute tasks for which no standard output containing the pilot id could be retrieved. These pilots cannot be identified from infrastructure-level logs. It also reveals that a significant fraction of the workload measured by EGI does not come from applications but from artifacts introduced by pilot managers. Figure 3. Number of submitted pilot jobs (left), and consumed CPU and wall-clock time (right) by the infrastructure (EGI) and the science gateway (VIP). Traces acquired at the science-gateway level provide fine-grained information about tasks, which is usually not possible at the infrastructure level. Figure 4 (left) shows the distributions of download, upload and execution times for successfully completed tasks. Distributions show a substantial amount of very long steps. Figure 3 (right) shows the occurrence of 6 tasklevel errors. These error codes are application-specific and not accessible to infrastructure level archives. Figure 4. Different steps in task life (left) and task error causes (right). Last, bag-of-tasks (BoT) can be properly identified from the science-gateway level, which is not the case at the infrastructure level. For instance, [6] detects bags of tasks as tasks submitted by a single user in a given time interval. However, this /88

31 method is very inaccurate and its use may have important consequences on works based on such detection. Figure 5 presents the comparison of BoT characteristics obtained from the described method and VIP. BoTs in VIP were extracted as the tasks generated by the same activity in a workflow execution and are considered as ground truth (named Real Non-Batch for single BoTs and Real Batch for others). Analogously, we name Non-Batch and Batch BoTs determined by the method. The method considers that 90% of BoT sizes ranges from 2 to 10 while these batches represents about 50% of Real Batch. Moreover, single BoTs are overestimated up to 400% on their durations. Both, single and batches, are underestimated by about 30% on inter-arrival times and up to 25% on consumed CPU times. Figure 5. Cumulative Distributed Function (CDF) of characteristics of batched and non-batched submissions: BoT sizes, duration per BoT, inter-arrival time and consumed CPU time. Application to workflow self-healing Distributed computing infrastructures (DCI) are becoming daily instruments of scientific research, in particular scientific gateways [7] developed to allow scientists to transparently run their analyses on large sets of computing resources. Operating these gateways require an important human intervention to handle operational incidents. One strategy to cope with these incidents is to automate such operations by using a healing process that could autonomously detect and handle them. The self-healing process presented in [8] handles incidents by automating such operations through a MAPE-K loop: monitoring, analysis, planning, execution and knowledge. Figure 6 presents the MAPE-K loop of the healing process. The monitoring phase consists in collecting events (job completion and failures) or timeouts. In the analysis phase, incident degrees and levels are determined from events and execution logs (historical information) extracted from the science-gateway archive. Then, an incident is selected by using a combination of roulette wheel selection and association rules (planning phase). Roulette wheel selection assigns a proportion of the wheel to each incident level according to their probability and a random selection is performed based on a spin of the roulette wheel. Association rules are used to identify relations between levels of different incidents based on historical information. Finally, a set of actions is performed to handle the selected incident. Incident level numbers and thresholds values are set from visual mode detection from histograms based on error causes and task sub-steps durations. The healing process was implemented in the Virtual Imaging Platform and deployed in production. It uses a subset from the science-gateway archive as historical information knowledge. Results presented hereafter show the ability of the healing process to improve workflow makespan in case of recoverable incidents and quickly identify and report critical issues. Experiments were conducted on two workflow activities: FIELD-II/pasa and Mean-Shift/hs3. The former consists of 122 invocations of an ultrasonic simulator on an echocardiography 2D data set. It is a data-intensive activity that transfers about 210 MB of data and consumes up to 15 minutes of CPU time. The last has 250 CPU-intensive application invocations of an image filtering application that consumes up to 1 hour and transfers about 182 MB of data. Figure 7 shows the makespan of both applications for a correct execution where all the input files exist and the application is supposed to run properly and produce the expected results. The makespan was considerably reduced in all repetitions with speed-up values ranged from 1.3 to 4. 29/88

32 Figure 6. MAPE-K loop of the healing process. Figure 7. Execution makespan for FIELD-II/pasa (left) and Mean-Shift/hs3 (right) for a correct execution. Conclusion We presented a science-gateway workload archive containing detailed information about users, pilot jobs, tasks and bag of tasks. First, we illustrated the added value of science-gateway workloads compared to infrastructure-level traces using information collected by the Virtual Imaging Platform in 2011/2012. Second, we showed an applicability of the workload archive on a healing process to cope with workflow execution incidents by quantifying them through historical execution information. Results show that the self-healing method proposed in [8] speeds up execution up to a factor of 4. Traces acquired by the Virtual Imaging Platform will be regularly made available to the community in the Grid Observatory. We hope that other science-gateway providers could also start publishing their traces so that computer-science studies can better investigate production conditions. References [1] A. Iosup, H. Li, M. Jan, S. Anoep, C. Dumitrescu, L. Wolters, D.H.J. Epema, The grid workloads archive, in Future Generation Computer Systems, 24(7) (2008) [2] R. Ferreira da Silva, S. Camarasu-Pop, B. Grenier, V. Hamar, D. Manset, J. Montagnat, J. Revillard, J. R. Balderrama, A. Tsaregorodtsev, T. Glatard, Multi-Infrastructure Workflow Execution for Medical Imaging Simulation in the Virtual Imaging Platform, in HealthGrid Conference 2011, Bristol, UK (2011) [3] C. Germain-Renaud, A. Cady, P. Gauron, M. Jouvin, C. Loomis, J. Martyniak, J. Nauroy, G. Philippon, M. Sebag, The grid observatory, in IEEE International Symposium on Cluster Computing and the Grid, (2011) [4] T. Glatard, J. Montagnat, D. Lingrand, X. Pennec, Flexible and Efficient Workflow Deployment of Data-Intensive Applications on Grids with MOTEUR, in International Journal of High Performance Computing Applications (IJHPCA), 22(3) (2008) [5] A. Tsaregorodtsev, N. Brook, A. C. Ramo, P. Charpentier, J. Closier, G. Cowan, R. G. Diaz, E. Lanciotti, Z. Mathe, R. Nandakumar, S. Paterson, V. Romanovsky, R. Santinelli, M. Sapunov, A. C. Smith, M. S. Miguelez, A. Zhelezov, DIRAC 3. The New Generation of the LHCb Grid Software, in Journal of Physics: Conference Series, 219(6) (2009) [6] A. Iosup, M. Jan, O. Sonmez, D. Epema, The characteristics and performance of groups of jobs in grid, in Euro-Par (2007) [7] S. Gesing, J. van Hemert, Concurrency and Computation: Practice and Experience, in Special Issue on International Workshop on Portal for Life-Sciences 2009, 23(3) (2011) [8] R. Ferreira da Silva, T. Glatard, F. Desprez, Self-healing of operational workflow incidents on distributed computing infrastructures, in 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), Ottawa, Canada (2012) /88

33 SysFera-DS : Un portail d'accès unifié aux ressources des centres de calcul. Mise en application à EDF R&D Benjamin Depardon (1), Samuel Kortas (2), Boris Daix (2), Renaud Barate (2) (1) benjamin.depardon@sysfera.com, SysFera, 13 avenue Albert Einstein, Villeurbanne (2) {samuel.kortas, boris.daix, renaud.barate }@edf.fr, EDF R&D SINETICS, 1 avenue du Général de Gaulle, BP 408, Clamart Cedex Overview There is a complex and widely diverse set of distributed platforms (e.g., workstations, clusters, supercomputers, grids, clouds) available to users. As users often seek ease of use first and foremost, many of these platforms are not used to the maximum of their potential, and users often make do with sub-optimal performance.. Engineers or researchers should not need to know the characteristics of the machines they have access to, be they static (e.g., performance, capacity) or dynamic (e.g., availability, load). They should be able to launch their application and let the system take care of how and where their application is run to ensure the optimal performance. For the system administrator, managing a set of heterogeneous machines can become a nightmare. Making the most of them, at the lowest possible cost, is close to impossible without using a standard set of tools accessible from a unique interface. Due to the complexity of the infrastructure and the wide heterogeneity of users, applications and available tools, EDF R&D has to cope with daily problems such: "How do I connect to this remote machine? "How do I run a job on this specific batch scheduler? "How do I manage my remote files?" Why don t I have a single account to access all of these resources Clearly, scientists wish to concentrate on their main field of expertise such as CAD modeling, fluid dynamics or structural mechanics simulations without having to deal with the complexity of the infrastructure. EDF R&D and SysFera 1 have co-developed a solution named SysFera-DS that provides end-users with a unified and simple view of the resources, and which can be addressed from a web portal (the WebBoard), the command line, or through several APIs for advanced users for an easy integration into simulation tools such as Salome. SysFera-DS provides single-sign-on for all of the heterogeneous resources, and functionalities such as resource monitoring, task and file management. Enjeux scientifiques, besoin en calcul, stockage et visualisation En 2012, EDF R&D dispose en interne de 5 ressources dédiées au calcul intensif : un BlueGene/P de 3768 cœurs, sous LoadLeveler ; un BlueGene/Q de cœurs, sous LSF ; un cluster de 1984 cœurs Intel Xeon X7560 Nehalem-EX sous Torque/Maui ; un cluster de 384 cœurs Intel Xeon X7560 Nehalem-EX sous LSF ; un cluster de cœurs Intel Xeon X5670 Westmere sous SLURM. Cette infrastructure évolue régulièrement pour accroître la puissance de traitement (calcul, stockage, échange) d EDF R&D. Le besoin est ici de développer un logiciel pour : Simplifier l accès à l infrastructure informatique à haute performance d EDF aux utilisateurs et les développeurs d applications scientifiques. Uniformiser et de standardiser l accès à l infrastructure informatique à haute performance d EDF. En particulier, ce logiciel est interfacé avec SALOME (Bergeaud et al. 2010). SALOME est co-développé par EDF et le CEA et constitue une plateforme générique open-source (licence L-GPL) qui propose des outils de pré/post-traitement et de couplage de codes de calcul pour la simulation numérique. SALOME est utilisée comme une plateforme d'intégration de codes de calcul numérique afin de créer une nouvelle application à partir des composants de base de SALOME et des codes intégrés dans cette plateforme. SALOME. Basée sur une architecture ouverte et flexible faite de composants réutilisables. SALOME offre en particulier des fonctionnalités : De modélisation et de liaison CAO-Maillage, De mise en données et préparation des calculs, De conception et de supervision de schéma de calcul (couplage, calcul paramétrique, distribution de calcul), De gestion de calcul (lancement et suivi) sur machine distante, De post-traitement des résultats de ces calculs. SysFera-DS : un intergiciel réparti et scalable d'accès à l'infrastructure EDF R&D et SysFera co-développent un intergiciel distribué open-source qui simplifie l accès à des ressources de calcul, et plus particulièrement aux moyens de calcul HPC internes d EDF. Ce logiciel est constitué de quatre modules : /88

34 UMS (User Management System) : en charge de l authentification, gestion des droits d accès et du single-sign-on en se basant sur ssh, LDAP et une base de données. IMS (Information Management System) : s occupant des métriques sur la plate-forme telles que la charge CPU et mémoire, la surveillance des queues des batch schedulers, la gestion du cycle de vie des processus Ces métriques sont principalement pour les administrateurs, mais également pour les utilisateurs avancés. FMS (File Management System) : gérant les fichiers sur les machines distantes. L utilisateur peut ainsi créer ou supprimer des fichiers ou dossiers, modifier les propriétés des fichiers (droits d accès, propriété ), transférer des fichiers de manière synchrone ou asynchrone entre n importe quelle machine (locale ou distante) en se basant sur les outils scp ou rsync. Cela permet à l utilisateur de transférer de très grandes quantités de données entre par exemple deux machines distantes sans avoir à se préoccuper de la gestion des processus de copie. TMS (Task Management System) : supportant la gestion et l exécution de jobs sur différents types de batch schedulers (SLURM, LSF, LoadLeveler, Torque, SGE ). Il fournit un identifiant de job unique sur toute la plateforme, quelque-soit le nombre et le type des batch schedulers, et permet d écrire des scripts d une manière générique complètement indépendante du type de batch scheduler sous-jacent. Ainsi, l utilisateur n a pas à se préoccuper des variables et commandes spécifiques aux batch schedulers : un seul script peut être utilisé, SysFera-DS s occupe de gérer la conversion des variables et options en fonction de l infrastructure sous-jacente. TMS permet également à l utilisateur de sélectionner sur quelle machine de calcul il souhaite faire tourner son job, ou de laisser SysFera-DS choisir la «meilleure» ressource en fonction de métriques de charge. Toutes ces fonctionnalités sont disponibles sous forme de commandes UNIX exécutables en ligne de commandes, et via de quatre autres APIs (C++, Java, Python et webservices). Ces dernières permettent une intégration aisée de la solution au sein d outils de simulation tels que la plate-forme SALOME. Au dessus de cette intergiciel, nous avons également développé un portail web : SysFera-DS WebBoard 2. Via une interface Web, nécessitant un browser supportant HTML 5, le WebBoard rend accessible à l utilisateur, quelque soit son OS, de manière graphique toutes les fonctionnalités sous-jacentes. Cela permet aux utilisateurs non-experts en informatique de faire tourner leurs simulations rapidement à l aide de quelques clics en bénéficiant d'une manière immédiate de toute la puissance de calcul haute performance accessible en interne. La Figure 1 présente une vue d ensemble de la plate-forme déployée à EDF R&D. Elle est actuellement composée de cinq clusters internes, dont quatre sont actuellement gérés avec SysFera-DS et accessibles depuis le WebBoard. Figure 1. SysFera-DS déployé à EDF R&D. Contraintes de l environnement EDF R&D La Figure 2 présente la solution à une des contraintes et difficultés rencontrées : la gestion des utilisateurs. L infrastructure d EDF R&D ne fournit pas de single-sign-on sur l ensemble de l infrastructure : chaque cluster est géré indépendamment, certains utilisent un LDAP pour l authentification, d autres non. Les utilisateurs se retrouvent donc avec plusieurs logins différents associés à des mots de passe ou clés ssh à gérer pour se connecter aux différentes ressources. SysFera-DS gère et dissimule cette hétérogénéité, sous la contrainte supplémentaire qu aucune partie de SysFera-DS ne peut avoir de privilèges root sur l infrastructure, ce qui est une contrainte forte lorsqu il faut être capable d exécuter les commandes à distance avec la bonne identité. Nous avons donc résolu ces problématiques de la manière suivante : Les utilisateurs peuvent se connecter à SysFera-DS à l aide d un simple couple identifiant/mot de passe. Ces identifiants sont vérifiés soit dans une base de données spécifique, soit dans un ou plusieurs LDAPs en même temps. Une fois ces identifiants vérifiés, l utilisateur a une session SysFera-DS d ouverte, et il peut alors interagir avec la plate-forme. Au sein d une session, chaque commande devant être exécutée à distance, est réellement exécutée avec le bon compte utilisateur en utilisant des connexions ssh : l utilisateur donne le droit à SysFera-DS d accéder à ses comptes locaux sur les machines distantes à l aide de clés ssh. Ainsi, l identité est préservée, et aucune surcouche 2 Une démonstration en ligne est disponible sur 32/88

35 SeD SysFera-DS SeD SeD de gestion des utilisateurs et de la sécurité n est ajoutée, SysFera-DS se repose sur les politiques locales déjà mises en place. Il est important de souligner que ce cas d utilisation est courant, particulièrement lorsque vous devez interconnecter plusieurs centres de calcul : chacun peut avoir ses propres politiques de sécurité. LDAP1,2...n Identification DB (2) Retreive identification credentials Site 1 /home/bobby (5) ssh as Bobby End-User Computer Site 2 /home/bob1 (5) ssh as Bob1 (1) Open session (3) Send requests... (6) Close session Site 3 /home/bob (4) Use global ID (5) ssh as Bob Figure 2. Single Sign On. Un autre défi courant est l exécution d un logiciel distribué sur une infrastructure protégée avec des firewalls. Dans notre cas, seul ssh peut être utilisé entre les différents sites. Ce cas est fréquent à bon nombre de centres de calcul. Nous avons donc introduit des agents spécifiques dans notre plate-forme qui ont le rôle d encapsuler toutes les communications internes à SysFera-DS dans un flux ssh. Ainsi, même si au sein d un réseau 1 toutes les connexions restent possibles, mais sont bloquées vers un réseau 2 hormis via ssh, SysFera-DS permet malgré tout des communications globales entre tous les réseaux à l aide de ces «forwarders». Résultats scientifiques Depuis Juillet 2011, SysFera-DS a été installé avec succès sur quatre calculateurs internes. Cet Intergiciel nous permet d'y soumettre, suivre ou annuler des travaux en utilisant les mêmes commandes. L'accès à ces ressources en est grandement amélioré (Bergeaud V., October 17-21, 2010) (Kortas S., December 2009) (Kortas S., April 2009) pour l'utilisateur : il n'est plus besoin de se connecter aux frontaux des machines et l'utilisateur peut passer l'ensemble de ses requêtes directement depuis son poste personnel. L'accès aux fichiers est également simplifié et plus naturel : qu'ils soient locaux ou distants, il suffit de faire précéder leur chemin du nom de la machine qui les héberge pour y accéder de façon transparente sans même avoir à s'authentifier. SYSFERA-DS propose également de nouveaux services comme les transferts asynchrones ou la synchronisation de répertoires. Pour l'ensemble des utilisateurs, cet accès facilité aux ressources ouvre la voie à leur utilisation plus naturelle et efficace. À noter entre autre, que Il n'est plus besoin de se préoccuper de détails comme la syntaxe particulière d'un ordonnanceur, le nom réseau de la machine, son propre login ou mot de passe. Seule l'authentification initiale au middleware est requise. le passage d'une machine à une autre est plus immédiat : dans le cas d'un code porté sur les deux supercalculateurs, seul le remplacement du nom de la machine à la soumission d'un job suffit. L'utilisateur conserve la même vue des ressources qu'il utilise (fichiers ou jobs) depuis l'ensemble des machines auxquelles il se connecte. Le transfert de fichier important en taille est moins problématique car il est asynchrone et entièrement pris en charge par l'intergiciel. Pour les exploitants, la présence de cette couche d'abstraction rend possible une évolution plus dynamique des ressources pour peu que l'interface avec l'intergiciel SYSFERA-DS soit préservée. Pour les développeurs d'applications, la standardisation de ces commandes offre l'opportunité d'un développement plus portable, indépendant des spécificités matérielles et logicielles de l'infrastructure. 33/88

36 Figure 3. Utilisation de SysFera-DS depuis SALOME. En particulier, le client SYSFERA-DS est désormais livré avec la plate-forme SALOME (voir Figure 3). Via l'interface graphique du gestionnaire de calcul (module JOBMANAGER), de cette plate-forme, la soumission de travaux sur les moyens de calculs adressés par l'intergiciel est transparente et apparaît comme un choix supplémentaire aux gestionnaires de batch classiques déjà disponibles dans SALOME. L'intérêt de cet interfaçage est à court terme pour SALOME de pouvoir immédiatement accéder par ce biais à toute nouvelle machine intégrée à SYSFERA-DS sans nécessiter la moindre réinstallation ou mise à jour nécessaire. À moyen terme, cette stratégie de répartition des rôles présente l'avantage pour SALOME de bénéficier de fonctions avancées ultérieurement disponibles dans SYSFERA-DS (réservation de ressources, de répartition de charge entre différents clusters, publication d'application...). Conclusion et travaux futurs De nombreuses nouvelles fonctionnalités sont actuellement à l étude pour les inclure dans les prochaines versions de SysFera-DS, par exemple : Visualisation distante : télécharger les fichiers de résultats sur le poste de travail pour les post-traiter peut être très long, et donc inefficace. Il est souvent plus rentable de les traiter directement à distance, et de fournir une solution de visualisation distante pour accéder aux logiciels de post-traitement. Nous prévoyons d ajouter des fonctionnalités de visualisation distante dans SysFera-DS, plus particulièrement dans le WebBoard. Desktop computing : les clusters sont efficaces pour les grosse simulations, mais pour des calculs plus petits et indépendants, les ressources de calcul que représentent les postes de travail peuvent être utilisées quand leurs propriétaires ne les utilisent pas. Des solutions existent pour gérer ces ressources, telle que BOINC (Anderson, 2004). Nous prévoyons d interfacer TMS avec BOINC de telle façon qu il soit vu comme une sorte de batch scheduler particulier. Comme montré sur la Figure 1 deux autres centres de calcul pourraient être rendus disponibles pour EDF R&D à travers SysFera-DS : le CCRT ( Centre de Calcul Recherche et Technologie ) et le TGVD ( Très Grand Volume de Données ). Via SYSFERA-DS, ces ressources externes seraient alors accessibles. Bibliographie Anderson, D. (2004). BOINC: A system for public-resource computing and storage. Grid Computing, Proceedings. Fifth IEEE/ACM International Workshop on (pp. 4-10). IEEE. Bergeaud, V., & Lefebvre, V. (October 17-21, 2010). SALOME: a software integration platform for multi-physics, preprocessing and visualization. Joint International Conference on Supercomputing in Nuclear Applications and Monte Carlo 2010 (SNA + MC2010). Hitotsubashi Memorial Hall, Tokyo, Japan,. Kortas, S. (April 2009). Fonctionnalités attendues d'un portail scientifique d'accès aux ressources de Calcul Haute Performance. EDF Internal Report H-I2D FR. Kortas, S., Mouton, C., Ribes, A., & Dutka-Malen, I. (December 2009). Accès standardisé aux ressources HPC : rôles, cas d'utilisations, et premiers éléments d'architecture fonctionnelle. EDF Internal Report H-I2D FR. 34/88

37 GeoQAIR : quantification de l apport d une plateforme satellitaire d observations Géostationnaires pour la surveillance de la Qalité de l AIR en Europe Maxim Eremenko(1), David Weissenbach(2), Pasquale Sellitto (3), Juan Cuesta (4), Gilles Forêt (5), Gaëlle Dufour (6) (1) maxim.eremenko@lisa.u-pec.fr, Laboratoire Inter-universitaire des Systèmes Atmosphériques, LISA/IPSL, Universités Paris Est Créteil et Paris Diderot, CNRS/INSU UMR 7583, Créteil, France (2) david.weissenbach@upmc.fr, Institut de physique du globe de Paris, (CNRS / INSU / IDG), Paris, France (3) pasquale.sellitto@lisa.u-pec.fr, Laboratoire Inter-universitaire des Systèmes Atmosphériques, LISA/IPSL, Universités Paris Est Créteil et Paris Diderot, CNRS/INSU UMR 7583, Créteil, France (3) juan.cuesta@lisa.u-pec.fr, Laboratoire Inter-universitaire des Systèmes Atmosphériques, LISA/IPSL, Universités Paris Est Créteil et Paris Diderot, CNRS/INSU UMR 7583, Créteil, France (5) gilles.foret@lisa.u-pec.fr, Laboratoire Inter-universitaire des Systèmes Atmosphériques, LISA/IPSL, Universités Paris Est Créteil et Paris Diderot, CNRS/INSU UMR 7583, Créteil, France (6) gaelle.dufour@lisa.u-pec.fr, Laboratoire Inter-universitaire des Systèmes Atmosphériques, LISA/IPSL, Universités Paris Est Créteil et Paris Diderot, CNRS/INSU UMR 7583, Créteil, France Overview : Monitoring of air quality (AQ) and its transport at the continental scale, as well as the development of efficient forecast systems for air quality is one of the issues included in the GMES (Global Monitoring for Environment and Security) European Programme for the establishment of a European capacity for Earth Observation. The availability of satellite instruments which have the ability to monitor tropospheric ozone in the lowermost troposphere would be a step forward for this system. To monitor small scale and short term processes as involved in pollution event development, a geostationary Earth orbit (GEO) observing system is particularly well adapted. Future GEO missions dedicated to air quality monitoring using thermal infrared (TIR) instruments are planned to be operating over the USA, Japan and Korea, while existing and planned missions over Europe are not well adapted for this task. One of the objectives of the GeoQAIR project is to evaluate different satellite instrument concepts for their ability to monitor AQ and in particular quantify the possible impact for AQ forecasting. Four instruments have been considered for this study: the existing instrument IASI on MetOp-A (Low Earth Orbit LEO mission), the planned IASI-NG on the EPS-SG platform (LEO mission) and IRS on Sentinel4/MTG platform (GEO mission mainly dedicated to meteorology) and a new GEO mission concept, MAGEAQ, dedicated to AQ monitoring and proposed at the last Earth Explorer 8 call of ESA. Pseudo-observations for the four instruments have been generated to simulate one month of ozone observations over Europe. About 45 millions of individual measurements have been simulated using the EGI facilities. A first analysis of the performances of the different instruments to measure ozone in the lowermost troposphere demonstrates that the short time and space scale processes implied in air pollution development will not be correctly apprehended with the current existing and planned missions. Dedicated instrument with sufficient spectral resolution and signal to noise ratio, as proposed within the MAGEAQ mission concept, are necessary to correctly represent these processes. Enjeux scientifiques, besoin en calcul, stockage et visualisation : Bien que la pollution de l air soit le fait d émissions localisées et se développe à l échelle locale la plupart du temps urbaine, des processus comme le transport, les échanges verticaux, l interaction avec des sources d émissions naturelles moins localisées renforçant la production de polluants induisent un impact jusqu à une échelle continentale voire hémisphérique. Il est donc nécessaire d être capable de surveiller et quantifier la qualité de l air, en particulier l ozone, à grande échelle. Dans le cadre du programme européen GMES (Global Monitoring for Environment and Security), des systèmes de surveillance et prévision de la qualité de l air couplant modèles et observations se mettent en place. Concernant les observations, les réseaux de mesure de surface actuels ne permettent pas une couverture optimale de l Europe. Par ailleurs, ces observations ne permettent pas de documenter les échanges verticaux et la représentativité des mesures n est pas toujours en adéquation avec celle des modèles. Les observations satellitaires permettent de palier en partie à ces limitations en apportant une information sur la verticale, une couverture spatiale homogène (en l absence de nuages) et une résolution horizontale en accord avec la résolution des modèles. Le développement des observations satellitaires dans l infrarouge thermique et de méthodes d analyse performantes (Eremenko et al., 2008) ces dernières années a permis une avancée en particulier avec l instrument IASI sur le satellite MetOp-A (Clerbaux et al., 2009). Plusieurs études ont montrées l intérêt de telles données pour la détection et le suivi d évènements de pollution à l ozone (Eremenko et al., 2008, Dufour et al., 2010) ainsi que pour l évaluation et l assimilation dans les modèles (Zyryanov et al., 2012, Coman et al., 2012). Cependant, pour une surveillance pertinente de la qualité de l air, il est nécessaire de disposer d instruments adaptés à la mesure d ozone dans les plus basses couches de la troposphère et au suivi de processus se développant sur des échelles spatiotemporelles relativement faible. Un des objectifs du projet GeoQAIR est d évaluer différents concepts d instrument satellitaire 35/88

38 pour mesurer l ozone dans la basse troposphère et quantifier l impact de telles observations dans un système de prévision de la qualité de l air européenne. Quatre instruments sont considérés dans cette étude : l instrument IASI en opération sur le satellite MetOp-A, les instruments prévus, vers 2020, IASI-NG sur la plateforme EPS-SG et IRS sur la plateforme Sentinel4/MTG ainsi qu un nouveau concept de mission, MAGEAQ, dédiée spécifiquement à la surveillance de la qualité de l air. Des pseudo-observations pour les 4 instruments ont été simulées pour représenter un mois d observations sur l Europe. Cela a nécessité la génération d environ 45 millions de mesures individuelles, sachant que la simulation d une mesure prend environ une minute. Trois mois de production intensive sur la grille EGI a été nécessaire pour générer l ensemble des pseudo-observations. Développements, outils, utilisation des infrastructures : La génération des pseudo-observations satellitaires consiste à simuler le signal qui serait mesuré par l instrument (la radiance) à partir d une atmosphère vraie de référence, donnée généralement par un modèle de chimie transport atmosphérique et d en extraire l information concernant la distribution verticale de la molécule cible, ici l ozone. Il s agit de l inversion des mesures. Pour cela, nous utilisons le code de transfert radiatif KOPRA et son module d inversion KOPRAFIT - Code de transfert radiatif KOPRA Le code de transfert radiatif KOPRA a été développé par l IMK (Institut für Meteorologie und Klimaforschung, Karlsruhe, Allemagne). Il permet de résoudre l équation du transfert radiatif dans le domaine spectral de l infrarouge pour des instruments de type spectromètres et ainsi de calculer la radiance vue par ce type d instrument pour différentes géométries d observation (limbe, nadir). Pour le calcul du transfert radiatif, l atmosphère est découpée en couches concentriques (100m d épaisseur) dites homogènes, c est-à-dire dans lesquels température, pression et concentration de chaque espèce moléculaire présente dans la couche sont considérées constantes. Le processus d interaction matière-rayonnement (absorption, émission etc) sont résolus et la radiance à la sortie de la couche considérée calculée en fonction du trajet optique dans la couche. Par une procédure itérative, la radiance au niveau de l observateur (le satellite) est ainsi calculée et convoluée par les caractéristiques instrumentales - Code d inversion KOPRAFIT Le code d inversion KOPRAFIT permet, via la minimisation de la norme entre la radiance observée et la radiance calculée (par KOPRA) de restituer la concentration de l espèce cible en fonction de l altitude. Le problème étant non linéaire, une procédure itérative est nécessaire pour atteindre une convergence raisonnable. Le traitement d une mesure satellitaire (un spectre de radiance) est une tache de très courte durée (environ 1min). En revanche, la couverture spatiale et la rapidité de la mesure conduisent à des flux importants des données. Pour donner un ordre de grandeur, pour le traitement des observations d un instrument en basse orbite (IASI par exemple) sur l Europe environ pixels sont à traiter pour chaque passage (matin ou soir). Dans le cas d un instrument géostationnaire il s agit de l ordre de pixels par jour. Les taches d analyse étant courtes et indépendantes font de ce type de traitement une application particulièrement bien adaptée a la grille car elles peuvent être exécutées en parallèle et sans synchronisation. Pour le déploiement de l analyse sur EGI, les codes KOPRA et KOPRAFIT ont été adaptés pour permettre une compilation statique pouvant s exécuter sur tous les types de machines de la grille. Un moteur de gestion des jobs sur la grille GEPS (Generic engine for parametric studies) a été développé et permet de gérer l envoi, les calculs sur la grille de nos applications et la récupération des résultats sur une machine locale pour leur utilisation géophysique ultérieure. Le GEPS est basé sur les technologies disponibles sur la grille et sur les applications existantes. La référence sur un exemple de telles applications peut être trouvé sur le site de 4th EGEE User Forum : L organisation virtuelle (VO) utilisée est ESR (Earth Science Research). Les ressources de cette VO ont été sollicitées durant environ 4 mois pour effectuer les calculs. Les taches d analyse ont était groupées par 200 pour optimiser le temps d envoi des entrées et de récupération des résultats. De faibles pertes de données ont été constatées ce qui a demandé une exécution réitérée pour les résultats perdus. Le volume et le temps de cette tâche n était pas important par rapport à la production totale. Résultats scientifiques : Notre approche consiste à utiliser un champ d ozone simulé par un modèle de chimie-transport (MOCAGE) qui est considéré comme la référence ou «pseudo-réalité». Un code de transfert radiatif (KOPRA) permet de simuler les spectres de radiance qui seraient mesuré par chaque instrument. Les pseudo-observations d ozone troposphérique sont alors obtenues en inversant ces spectres à partir du code d inversion KOPRAfit. Nous avons évalué les performances de différents instruments satellitaires (IASI, IASI-NG, IRS et MAGEAQ) en comparant la qualité de ces pseudo-observations. Notre étude a permis de quantifier de manière détaillée l apport des instruments spatiaux de nouvelle génération : IASI-NG 36/88

39 et MAGEAQ, par rapport à un instrument existant (IASI) ou un déjà programmé (IRS). Les résultats ont montré que l amélioration de la résolution verticale apportée par IASI-NG est d environs 50%, avec une sensibilité moyenne à une altitude 0,5 km plus base que celle d IASI. L évolution des panaches d'ozone troposphérique à l'échelle régionale et locale est sensiblement mieux caractérisée par IASI-NG. Nous avons constaté une amélioration significative pour le suivi des panaches à l échelle temporelle de 2-3 jours, ce qui est important pour l'étude de la pollution urbaine. Pour les deux capteurs embarqués sur satellites géostationnaires, MAGEAQ et IRS, les pseudo-observations ont permis de démontrer très clairement qu IRS, la seule nouvelle mission géostationnaire européenne utilisant la bande de l infrarouge thermique, n'a pas la capacité pour observer l'ozone dans la basse troposphère. Par contre, MAGEAQ, l instrument proposé qui serait dédié à l observation de l ozone troposphérique, serait capable de mieux observer les concentrations d ozone de la basse troposphère (avec un degré de liberté entre la surface et 6 km d altitude et avec une sensibilité maximale à 3.0 km d altitude) par rapport aux instruments existants (IASI). Un exemple de pseudo-observations pour les 4 instruments spatiaux est montré sur la figure ci-dessous (concentration d ozone intégrée entre la surface et 6 km d altitude, en Dobson Units DU, pour le 20 Aout 2009 à 1000 TU). Un autre aspect qui a été étudie avec les pseudo-observations produites par l EGI est l'erreur introduite dans les OSSEs (Expériences de Simulation de Systèmes d'observation) en utilisant des approximations pour réduire le temps de calcul. En effet, nous avons pu montré que les approximations de pseudo-observations utilisées pour d autres études (Claeyman et al., 2011; Zoogman et al., 2012) peuvent être trop optimistes dans les cas où la tropopause est basse ou lorsque les concentrations d'ozone troposphérique sont co-localisées avec des zones de faible contraste thermique entre la surface et l air près de la surface. IASI. PSEUDO'OBSERVATIONS. IASI'NG. OZONE. 0..6km. PSEUDO'REALITY. IRS. MAGEAQ. Colonnes partielles d ozone intégrées entre la surface et 6 km d altitude au-dessus du niveau de la mer pour le 20 Aout 2009 à 1000 TU. A gauche, la pseudo-réalité utilisée comme référence (sorties du modèle de chimie-transport MOCAGE) et à droite, les pseudo-observations calculées sur la grille EGI pour les 4 instruments spatiaux (IASI, IASI-NG, IRS et MAGEAQ) Les résultats de notre étude ont été présentés dans différentes conférences internationales (voir, e.g., Sellitto et al., 2011) et elles sont en cours de publications dans des journaux scientifique internationaux (Sellitto et al, 2012a; Sellitto et al, 2012b). Perspectives : Disposant de l ensemble des pseudo-observations simulées pour les 4 instruments (IASI, IASI-NG, IRS, MAGEAQ), nous pouvons maintenant envisager d évaluer l apport de ces instruments dans un système de prévision de la qualité de l air. Pour cela, la méthode communément utilisée pour évaluer, à moindre coût, l apport d un nouveau système d observations n existant pas encore est la mise en œuvre d Expériences de Système d Observations Simulé ou OSSEs (Lahoz et al., 2005). Ces OSSEs consistent à utiliser les pseudo-observations de chaque instrument pour corriger, via l assimilation, les 37/88

40 modèles de prévision de la qualité de l air. L objectif est de consolider le concept de mission MAGEAQ, dédié à la surveillance de la qualité de l air en Europe. Pour cela, nous devons démontrer que ce concept de mission spatiale est robuste et nous devons quantifier son apport pour démontrer son intérêt aux agences spatiales française et européenne. Les OSSEs réalisées dans le projet permettront de quantifier l impact de pseudo-observations MAGEAQ par rapport à : (1) des observations satellitaires existantes IASI ; (2) des observations satellitaires programmées instrument IRS sur MTG/Sentinel 4 et IASI-NG au sein du programme EPS-SG d Eumetsat; (3) les observations des réseaux de surface. De plus, des nouvelles configurations instrumentales devront être évaluées. Notamment, à partir du couplage des observations à multiples bandes spectrales (infrarouge thermique, ultraviolet et visible) pour caractériser l ozone à proximité de la surface. Pour cela, un générateur des pseudo-observations d ozone à partir du couplage TIR+VIS+UV devra être développé et intégrée aux systèmes OSSEs déjà mis en place pour les pseudo-observations TIR seul (décrites précédemment). Références : Claeyman, M., Attié, J.-L., Peuch, V.-H., El Amraoui, L., Lahoz, W. A., Josse, B., Joly, M., Barré, J., Ricaud, P., Massart, S., Piacentini, A., von Clarmann, T., Höpfner, M., Orphal, J., Flaud, J.-M., and Edwards, D. P.: A thermal infrared instrument onboard a geostationary platform for CO and O3 measurements in the lowermost troposphere: Observing System Simulation Experiments (OSSE), Atmos. Meas. Tech., 4, , doi: /amt , 2011 Clerbaux, C., Boynard, A., Clarisse, L., George, M., Hadji-Lazaro, J., Herbin, H., Hurtmans, D., Pommier, M., Razavi, A., Turquety, S., Wespes, C., and Coheur, P.-F.: Monitoring of atmospheric composition using the thermal infrared IASI/MetOp sounder, Atmos. Chem. Phys., 9, , Coman A., G. Foret, M. Beekmann, M. Eremenko, G. Dufour, B. Gaubert, A. Ung, C. Schmechtig, J.-M. Flaud, and G. Bergametti, Assimilation of IASI partial tropospheric columns with an Ensemble Kalman Filter over Europe, Atmos. Chem. Phys., 11, , Dufour G., M. Eremenko, J. Orphal, J.-M. Flaud, IASI observations of seasonal and day-to-day variations of tropospheric ozone over three highly populated areas of China: Beijing, Shanghai, and Hong Kong, Atmos. Chem. Phys., 10, , Eremenko M., G. Dufour, G. Foret, C. Keim, J. Orphal, M. Beekmann, G. Bergametti, and J.-M. Flaud: Tropospheric ozone distributions over Europe during the heat wave in July 2007 observed from infrared Nadir spectra measured by IASI, Geophysical Research Letters 35, doi: /2008gl034803, Lahoz, W., A., R. Brugge, D. R. Jackson, S. Migliorini, R. Swinbank, D. Lary et A. Lee, An observing system simulation experiment to evaluate the scientific merit of wind and ozone measurements from the future SWIFT instrument, Q. J. R. Meteorol. Soc., 131, , Sellitto, P., Dauphin, P., Dufour, G, Eremenko, M., Coman, A., Forêt, G., Beekmann, M., Gaubert, B., Flaud, J.-M., Performance assessment of future LEO and GEO satellite infrared instruments to monitor air quality, Proceedings of the EUMETSAT Conference 2011, Oslo, Norway, 2011 Sellitto, P., Dufour, G, Eremenko, M., Coman, A., Cuesta, J., Dauphin, P., Forêt, G., Flaud, J.-M., Performance comparison of IASI and IASI-NG lower tropospheric ozone pseudo-observations, to be submitted to Atmos. Meas. Tech., 2012a Sellitto, P., Dufour, G, Eremenko, Cuesta, J., On the averaging kernels parametrization for the implementation of fast observing system simulation experiments targeted on tropospheric ozone observations, to be submitted to Atmos. Meas. Tech., 2012b Zoogman, P., D.J. Jacob, K. Chance, L. Zhang, P. Le Sager, A.M. Fiore, A. Eldering, X. Liu, V. Natraj, S.S. Kulawik, Ozone Air Quality Measurement Requirements for a Geostationary Satellite Mission. Atmos. Environ., 45, 7,143-7,150, 2011 Zyryanov D., G. Foret, M. Eremenko, M. Beekmann, J.-P. Cammas, M. D Isidoro, H. Elbern, J. Flemming, E. Friese, I. Kioutsioutkis, A. Maurizi, D. Melas, F. Meleux, L. Menut, P. Moinat, V-H Peuch, A. Poupkou, M. Razinger, M. Schultz, O. Stein, A. M. Suttie, A. Valdebenito, C. Zerefos, G. Dufour, G. Bergametti and J-M. Flaud, 3D evaluation of free tropospheric ozone simulations by en ensemble of regional Chemical Transport Models, Atmos. Chem. Phys., 12, , /88

41 Diffusion MRI simulation with the Virtual Imaging Platform Lihui Wang, Sorina Camarasu-Pop, Tristan Glatard, Yue-Min Zhu, Isabelle E. Magnin Université de Lyon, CREATIS ; CNRS UMR5220 ; Inserm U1044 ; INSA-Lyon ; Université Lyon 1. Overview Myocardial fiber architecture plays an important role in ensuring normal mechanical and electrical properties of the heart. However, due to limitations of existing imaging techniques, little is known about the fiber structure of in vivo human heart. Diffusion magnetic resonance imaging (dmri) is one of the most potential techniques for mapping in-vivo cardiac fiber architecture. However, in the absence of the ground truth information and with influence of MRI scanner noise and artifacts, it is difficult to evaluate how well the diffusion characteristics calculated from experimental dmri reflect the actual cardiac fiber microstructure properties. To cope with this issue, we propose a dmri simulator that simulates the diffusion of water molecules within a virtual cardiac fiber model with a Monte-Carlo approach, and calculates the diffusion images using the spin quantum theory. The noise-free and non-artifacts images from this simulation enable the evaluation of dmri image processing algorithms and the optimization of imaging parameters based on the model ground truth. To support its computing needs, the simulator was ported to the European Grid Infrastructure (EGI) through the Virtual Imaging Platform (VIP). The simulation of 16 billion water molecules, which would require 8 CPU years on a representative machine of the biomed virtual organization (VO), can now be achieved in one month. Much manual intervention is still required to compute such simulations though. Challenge and computing needs Despite decades of intensive cardiovascular research in basic and clinical sciences, very little information exists on the intrinsically three-dimensional (3D) fiber architecture of the human heart, which is however fundamental for a comprehensive understanding of the relations between mechanical function, hemodynamic, and adaptive structural changes in cardiac diseases. The only reason for this situation is that there is currently no means to access such in vivo 3D fiber architecture. Diffusion magnetic resonance imaging (dmri) [1] including diffusion tensor imaging (DTI) [2] appears as the new and perhaps the only way to access the 3D fiber architecture non-invasively for the human heart. However, due to the tissue property itself of the myocardium and the motion sensitivity of dmri technique, it is currently not possible to obtain in vivo cardiac fiber architecture. Moreover, even for the ex vivo dmri experiments, because of the limits of MRI scanner, the image resolution is about 2 mm which is not sufficient for investigating cardiac fiber properties [3]. To tackle this problem, we propose here a radically different approach which consists in modeling the 3D fiber architecture using multiphysical data from different imaging modalities working at different spatial resolutions and simulating the diffusion magnetic resonance images for both ex vivo and in vivo human heart. To this end, the myocardium of the human heart was imaged using polarized light imaging (PLI) [4] which gives us a map of fiber orientation with spatial resolution of µ m. Based on this information, an ex vivo virtual cardiac fiber structure (VCFS) was modeled. The diffusion behavior of water molecules in this VCFS was simulated by means of Monte- Carlo method [5]-[7], and the diffusion images in different directions were calculated using spin quantum theory. It is well known that Monte-Carlo simulation usually requires important computation resources to guarantee the simulation accuracy, but this requirement becomes even more stringent in our case. Knowing that for one fetus heart there are 707,672 fibers constructed in our VCFS model, and that 24,000 water molecules are simulated for each fiber, the simulation time is estimated at approximately 8 CPU years on a machine representative of the biomed VO. Grid computing provides an interesting solution to reduce the computation time. Simulation parallelization The straightforward static parallelization approach for Monte-Carlo simulations equally splits the simulation into p jobs, each job simulating m molecules in a subset of f cardiac fibers among the total number of fibers F. This results in Algorithm 1, executed on the computing nodes (workers). Worker: 1. Input: n1,..., nf: the f indices of the cardiac fibers to simulate 2. Download input data and simulation code 3. for i from 1 to f 4. for j from 1 to m 5. randomly choose one initial molecule position in fiber ni 6. simulate diffusion of molecule and contribution to DWI signal 7. end 39/88 1

42 8. end 9. write and upload molecule positions and signal contributions Algorithm 1: static parallelization of the simulation. As shown in [12], this approach is notably inefficient on large, heterogeneous, unreliable infrastructures such as EGI for the following reasons: The simulation time is bound by the performance of the slowest job. Failed jobs have to be resubmitted. Failed jobs do not contribute to the simulation (results are lost). To cope with these issues, the master-slave proposed in [12] was implemented. Checkpointing is also used, to avoid losing important amounts of computation in case the jobs are killed after several hours of execution. Algorithm 2 shows the pseudocode of the parallelized application. It has the following properties: The number of molecules simulated by a job is adjusted to the speed of its machine (see while loop in steps 3-11 of worker algorithm). Failed jobs can be ignored: failures would only lead to increased numbers of simulated molecules by successful jobs. Failed jobs contribute to the simulation thanks to checkpointing (step 8 of worker algorithm). Each job adapts its checkpointing period (see step 10 of worker algorithm) as follows:, where C is the checkpointing period expressed in molecules, NJ is the number of parallel computing jobs, T is the time in seconds needed to transfer the checkpointed result to/from the storage element, and is the computing speed of the worker node expressed in molecules per second. This ensures that checkpointed results can be downloaded and merged before the next checkpoint. The checkpointing frequency is thus adapted so that the merger can download and merge the results checkpointed by all parallel computing jobs between two checkpoints. Master: 1. N = F x m 2. n = 0 3. while ( n < N ) do 4. n = number of water molecules simulated by running and completed tasks 5. end 6. send stop signal to all tasks 7. cancel queued tasks Worker: 1. Download input data and simulation code 2. N = F x m 3. while stop signal not received and n < N do 4. randomly select one cardiac fiber from uniform distribution 5. randomly select one initial molecule position in the previously selected cardiac fiber 6. simulate diffusion of the molecule and contribution to DWI signal 7. every C iteration: 8. checkpoint molecule positions and signal contributions 9. report number of simulated molecules to master 10. adjust checkpointing frequency C 11. end Algorithm 2: dynamic parallelization of the simulation with checkpointing. Note that Algorithm 2 does not guarantee that an equal number of molecules is simulated in each cardiac fiber. Step 4 of the worker algorithm only guarantees that they are uniformly distributed in cardiac fibers. Results are finally merged together using simple additive operations. The merging order is not constrained as merging operations are associative and commutative. Thanks to checkpointing, results can be incrementally merged during the simulation. Merging is a critical task since partial results have to be transferred from sites distributed world-wide. Tools used and difficulties encountered The simulator was ported to the VIP portal described in [8]. This environment is a web-portal accessible at which gives access to some 10 simulators and counts more than 200 registered users. In a few clicks, users can launch parallel executions, monitor their status and download the final results when they are ready. The 40/88 2

43 simulators available in the portal are described as MOTEUR workflows [9], from which tasks are generated and executed using DIRAC [10] pilot jobs on the resources available to the biomed VO within the EGI grid. All computing resources supporting the biomed VO are available for the computation (about 100 clusters). DIRAC is responsible for matching simulation jobs to computing nodes. Synchronization between master and workers is ensured by a specific service developed in the DIRAC framework. The simulation code was significantly instrumented to support checkpointing, and to properly handle random generators to ensure statistical independence of all checkpoints. The simulator is developed in Matlab. To avoid licensing issues on distributed computing nodes, the code is compiled using the Matlab Compiler and deployed on the fly on the computing nodes with the Matlab Compiler Runtime (MCR). Although the simulator was ported to VIP, which should allow end-users to autonomously launch their computations, the simulation still had to be handled by grid experts with much manual intervention. The main difficulties were: 1) The very long duration of the simulation jobs (a few weeks if not interrupted). Simulation jobs were progressively killed by sites or system errors. New jobs had to be resubmitted periodically to maintain a sufficient number of running jobs. The simulation was launched in 10 different job batches, each with 500 jobs. The workflow had to be adapted so that the different job batches shared the same logical folders and that partial results could be merged all together to provide a single final output. 2) The merging of partial results distributed across the sites where they were produced. Each batch of 500 jobs produced on average 2000 files of approximately 500 megabytes each. Due to scheduled and unscheduled downtimes of biomed storage sites, file transfers had to be retried several times, sometimes over a few days. In addition, the merging process was memory-intensive and consumed very little CPU. It was thus manually launched on a local dedicated machine with 4 GB of RAM. Simulation results A 40-week fetus heart was imaged using the PLI system and, based on its angle map, the cardiac fiber was modeled by the orientated cylinder. The motion of each water molecule in this kind of structure was mimicked by the random walks and its displacement during one certain period was tracked, from which the phase shift was derived and diffusion signal attenuation caused by the diffusion was calculated. The sub-figure (a) in Fig.1 shows the simulated diffusion images in 12 different directions, sub-figure (b) is the 3D diffusion weighted (DW) image along z direction. From these DW images, the diffusion tensor field, fractional anisotropy (FA) and mean diffusion coefficient (MD) were calculated accordingly, as shown in Fig.2 The combination of PLI and DWI provides us not only the fiber orientation distribution but also FA and MD information. It takes advantage of the merit of high spatial resolution of PLI which compensates the insufficiency of experimental dmri. \ (a) DW images in 12 directions for one slice (b) DW image for the whole heart in one direction Fig. 1 The simulated diffusion weighted images for ex-vivo fetus heart. Simulation parameters: diffusion time=200 ms, b value= 2288 s/mm2, diffusion gradient directions=162, number of water molecules involved in the simulation= 16 billion. (a) Diffusion Tensor Image (b) MD (c) FA Fig. 2 Diffusion Tensor, MD and FA images. Diffusion coefficient used in the simulation is 10-3 mm 2 /s, the simulated MD ranges from mm 2 /s to mm 2 /s, FA changes from 0.31 to /88 3

44 These results correspond to 8 CPU years and were obtained in about one month using the resources available to the biomed VO on the EGI grid. The simulation was executed in production conditions using the VIP portal. The speed-up of each batch of simulation jobs was of approximately 140, but if we take into account the total time elapsed between the job batches, the average speed-up of the complete simulation is close to 80. Perspectives The simulated noise-free and non-artifact images can be used for evaluating diffusion image processing algorithms, such as denoising, k-space reconstruction, and motion correction. In addition, the simulation can help optimize the imaging parameters for high-b value imaging and q-space imaging. Furthermore, in vivo cardiac fiber models can be constructed based on PLI data and motion information from MRI cine sequences and as a result in vivo DW images can be simulated. As detailed in [12], load-balancing among computing resources is close to optimal for the simulation phase. However, there is still room for improving performance, especially in the merging phase: (i) the merging phase could be improved by using multiple parallel mergers as done in [13], (ii) the influence of the checkpointing frequency on the merging phase could be studied, (iii) the placement of partial simulation results on different storage locations could be investigated to reduce the cost of the merging phase. These could reduce the amount of manual intervention by grid experts which, to date, is still required to conduct such experiments. Acknowledgement We specially thank P.S. Jouk and Y. Usson for making the set of foetal heart data available for this study. The authors also acknowledge the support of EGI and in particular France Grilles for providing computing resources on the grid infrastructure. References [1] L. Minati and W. P. We, Physical Foundations, Models, and Methods of Diffusion Magnetic Resonance Imaging of the Brain: A Review, vol. 30, no. 5, pp , [2] D. Le Bihan, JF. Mangin, C. Poupon, C.A. Clark, S. Pappata, N. Molko and H. Chabriat, Diffusion tensor imaging: concepts and applications., Journal of magnetic resonance imaging: JMRI, vol. 13, no. 4, pp , Apr [3] D. Le Bihan, C. Poupon, A. Amadon, and F. Lethimonnier, Artifacts and pitfalls in diffusion MRI., Journal of magnetic resonance imaging: JMRI, vol. 24, no. 3, pp , Sep [4] P.S. Jouk, A. Mourad, V. Milisic, G.Michalowicz, A. Raoult, D.Caillerie and Y. Usson, Analysis of the fiber architecture of the heart by quantitative polarized light microscopy. Accuracy, limitations and contribution to the study of the fiber architecture of the ventricles during fetal and neonatal life., European journal of cardio-thoracic surgery: official journal of the European Association for Cardio-thoracic Surgery, vol. 31, no. 5, pp , May [5] E. Fieremans, Y.De Deene, S.Delputte, M.S.Ozdemir, Y.D Asseler, J.Vlassenbroeck, K.Deblaere, E. Achten and I. Lemahieu, Simulation and experimental verification of the diffusion in an anisotropic fiber phantom., Journal of magnetic resonance (San Diego, Calif.: 1997), vol. 190, no. 2, pp , Feb [6] L.H. Wang, Y.M. Zhu, H.Y. Li, W.Y. Liu, and I. E. Magnin, Multiscale modeling and simulation of the cardiac fiber architecture for DMRI., IEEE transactions on bio-medical engineering, vol. 59, no. 1, pp. 16-9, Jan [7] D. Le Bihan, The wet mind : water and functional neuroimaging., Physics in medicine and biology, vol. 52, no. 7, pp. R57-90, Apr [8] R. Ferreira da Silva, S. Camarasu-Pop, B. Grenier, V. Hamar, D. Manset, J. Montagnat, J. Revillard, J. R. Balderrama, A. Tsaregorodtsev, T. Glatard, Multi-infrastructure workflow execution for medical simulation in the virtual imaging platform, in: HealthGrid 2011, Bristol, UK, [9] T. Glatard, J. Montagnat, D. Lingrand, X. Pennec, Flexible and effcient workflow deployement of data-intensive applications on grids with MOTEUR, International Journal of High Performance Computing Applications (IJHPCA) 22 (3) (2008) [10] A. Tsaregorodtsev, M. Bargiotti, N. Brook, A. C. Ramo, G. Castellani, P. Charpentier, C. Cioffi, J. Closier, R. G. Diaz, G. Kuznetsov, Y. Y. Li, R. Nandakumar, S. Paterson, R. Santinelli, A. C. Smith, M. S. Miguelez, S. G. Jimenez, Dirac: a community grid solution, Journal of Physics: Conference Series (2008) 119 (6). [11] J. S. Rosenthal, Parallel computing and Monte-Carlo algorithms, Far East Journal of Theoretical Statistics 4 (1999) [12] S. Camarasu-Pop, T. Glatard, J. T. Moscicki, H. Benoit-Cattin, D. Sarrut, Dynamic partitioning of Gate Monte-Carlo simulations on egee, Journal of Grid Computing 8 (2) (2010) [13] S. Camarasu-Pop, T. Glatard, R. Ferreira da Silva, P. Gueth, D. Sarrut, and H. Benoit-Cattin, "Monte-Carlo Simulation on Heterogeneous Distributed Systems: a Computing Framework with Parallel Merging and Checkpointing Strategies", Future Generation Computer Systems, accepted for publication on 3/9/ /88 4

45 Hadoopizer : a cloud environment for bio-informatics data analysis Anthony Bretaudeau (1), Olivier Sallou (2), Olivier Collin (3) (1) anthony.bretaudeau@irisa.fr, INRIA/Irisa, Campus de Beaulieu, 35042, RENNES, Cedex, France (2) olivier.sallou@irisa.fr, INRIA/Irisa, Campus de Beaulieu, 35042, RENNES, Cedex, France (3) olivier.collin@irisa.fr, INRIA/Irisa, Campus de Beaulieu, 35042, RENNES, Cedex, France Overview: Biology is evolving into a big data science, particularly with the new sequencing technologies which have emerged during the last years. Cloud computing appears as one of the answers to face the rapidly increasing volume of bioinformatics data. Here we present a private cloud environment deployed on the GenOuest bioinformatics platform. After an overview of the software publicly available for bioinformatics treatments in the cloud, we present a new framework (Hadoopizer) which is a generic tool for the parallelisation of bioinformatics analysis in the cloud using the MapReduce paradigm. These developments are available online at this address: Contexte : L'émergence des nouvelles technologies de séquençage a transformé de manière radicale la Biologie qui est devenue une science générant des masses de données. Le changement d'échelle induit par cette génération massive de données nécessite de trouver de nouveaux modes de calcul, que ce soit pour les ressources mais également pour la façon de distribuer ces calculs. La démocratisation des appareils de séquençage dans les laboratoires complique la situation car tous les laboratoires ne disposent pas forcément d'une infrastructure adaptée pour le calcul. L'utilisation d'une ressource de type cloud apparaît donc comme une alternative intéressante pour accompagner l'évolution des laboratoires [1]. Les plates-formes bio-informatiques sont concernées au premier chef par l'évolution des techniques en Biologie et sont impliquées dans des réflexions sur ces nouveaux modes de calcul. La plate-forme bio-informatique GenOuest a lancé plusieurs projets afin d'obtenir un retour d'expérience sur l'apport des technologies du cloud et de l'utilisation de Map-Reduce pour l'analyse des données de séquençage. Le premier projet consiste en la mise en place d'un cloud privé basé sur OpenNebula. Le second projet repose sur l'exploration de Map-Reduce pour l'exploitation des séquences. A cet effet, un environnement de déploiement automatique Hadoop a été développé. GenoCloud : GenOuest a déployé un cloud de 120 cœurs, 470 Go de mémoire et 8 To de stockage pour proposer un environnement de démonstration et d expérimentation pour la communauté. Cet environnement est disponible à l'adresse Basé sur OpenNebula, ce cloud propose des images pré-configurées (réseau, accès par clé SSH, ), un proxy pour l'accès à partir de l'extérieur vers les applications web, ainsi que des outils de déploiement automatique d'environnement de calculs. Cela inclut pour le moment la possibilité de déployer un cluster Grid Engine ou un cluster Hadoop dynamiquement en sélectionnant le nombre de nœuds voulus et la possibilité de l'étendre, le tout s'effectuant via une interface graphique pour en faciliter l'usage. L'interface offre également un monitoring des instances ainsi créées. Ces images ont un but pédagogique, afin que les utilisateurs puissent tester simplement et efficacement leurs outils sans s'occuper de l'implémentation des couches techniques. Un outil de workflow extensible développé par GenOuest (Manband) sera bientôt implémenté de la même façon dans ces images. Un outil de messaging (RabbitMQ) permet aux applications de communiquer de façon robuste entre elles sans connaître la configuration de leurs voisines. Ce cloud propose également aux utilisateurs un accès disque partagé entre toutes les VM, allant au delà des solutions type EBS ou S3, car plus souple pour l'utilisateur habitué à des accès type NFS entre serveurs. Ceci facilite la transition ou les tests d'applications existantes. Chaque instance possède un montage automatique sur ce disque vers un répertoire personnel. Enfin, il supporte l'interface EC2 et propose un stockage compatible S3 pour permettre un passage simple vers un prestataire privé. 43/88

46 Hadoopizer : Un outil exploitant le framework Hadoop est en cours de développement afin d'évaluer l'apport de l'utilisation de MapReduce pour le traitement de données bio-informatiques. Cet outil, baptisé Hadoopizer, constitue un environnement générique pour l'utilisation de Hadoop en bio-informatique. L'outil est capable de prendre une ligne de commande traditionnelle et de lancer son exécution de manière distribuée sur des quantités importantes de données, en utilisant un cluster Hadoop déployé de façon automatique sur l'environnement de cloud de la plate-forme GenOuest. Hadoopizer propose un parallélisme à gros grain, concernant des traitements qualifiés d'embarrassingly parallel, c'est-à-dire où chaque sous-tâche est exécutée de façon indépendante des autres sous-tâches. D'autres outils bio-informatiques utilisant Hadoop sont disponibles [2,3,4,5,6,7] (tableau 1). Cependant, chacun de ces outils ne permet d'utiliser qu'un algorithme précis (assemblage, mapping). Implémenter d'autres algorithmes dans ce cadre impose des développements importants. Le logiciel Eoulsan [8] est un peu plus polyvalent puisqu'il propose de base plusieurs outils (tableau 1). Il offre aussi la possibilité d'intégrer d'autres outils grâce à une API Java, mais ceci nécessite un temps de développement non négligeable. Outil Application Évolutivité Programmes interfacés CloudAligner [3] Mapping + Algorithme spécifique CloudBurst [4] Mapping + RMAP Contrail [5] Assemblage + Algorithme spécifique Crossbow [6] Détection de SNPs + Bowtie + SOAPsnp Myrna [7] Expression différentielle + Bowtie + R Eoulsan [8] Expression différentielle ++ Bowtie, BWA, SOAP2, Gsnap, Gmap, R Tableau 1 : quelques outils bio-informatiques utilisant le cloud computing Il nous a semblé important de disposer d'un outil beaucoup plus polyvalent. La caractéristique principale de Hadoopizer est d'être générique en permettant l'exécution de n'importe quelle ligne de commande shell sur un cluster Hadoop. Il propose un framework qui permet d'encapsuler tout le programme, en prenant en charge la parallélisation des exécutions. Ceci apporte une grande souplesse d'utilisation, l'exploitation d'un nouvel algorithme ne nécessitant aucun développement spécifique. Ceci constitue un avantage important dans le domaine de la bio-informatique qui est caractérisé par une durée de vie relativement courte des logiciels d'analyse. Hadoopizer prend en charge différents formats de données couramment utilisés : fichiers de séquence fasta ou fastq ou encore alignements au format sam ou bam. Ces formats peuvent être utilisés comme données de sortie ou d'entrée ; dans ce cas, elles sont alors découpées et envoyées aux différents nœuds de calculs. Il est aussi possible d'utiliser des données statiques, qui doivent être entièrement accessibles en lecture sur chaque nœud (comme un génome de référence par exemple) : Hadoopizer prend alors en charge les transferts nécessaires pour que ces données soient accessibles sur tous les nœuds de calcul. Les transferts des données d'entrée et de sortie sont gérés par Hadoopizer à travers plusieurs protocoles (local, HDFS, S3). La compression de ces données est aussi supportée dans différents formats (gzip, bzip2). Il est possible de déployer automatiquement les binaires nécessaires à l'exécution sur tous les nœuds de calculs. Les binaires doivent être fournis sous forme d'une archive qui est envoyée puis décompressée automatiquement sur chaque nœud de calcul au début de l exécution. Enfin dans le cas d'un enchaînement de plusieurs outils, les données de sortie peuvent être enregistrées dans un fichier au format optimisé et placé sur le système de fichier HDFS du cluster Hadoop. Ceci permet de maximiser les performances de lecture pour une réutilisation comme données d'entrée d'un nouveau calcul. Résultats scientifiques : La première application sur laquelle a été testé cet environnement correspond au mapping de séquences sur un génome de référence. Ce type de traitement est très utilisé pour l'analyse de données de séquençage a haut débit. Dans ce cas 44/88

47 d'utilisation, on dispose d'un nombre important (quelques dizaines de Go) de séquences de faible taille (appelés 'reads', typiquement 100 caractères). On souhaite alors positionner chacun de ces reads sur un génome de référence disponible sous la forme d'une très longue séquence (de quelques Mo à quelques Go). Cet exemple est facilement parallélisable puisque chaque read peut être positionné indépendamment des autres reads. De nombreux algorithmes sont disponibles pour effectuer cette étape de mapping, chacun ayant des spécificités (tolérance aux erreurs dans les reads, support des gaps). Des analyses de mapping sur des jeux de données réels ont été menées en utilisant Hadoopizer sur le cloud privé de GenOuest. Deux algorithmes de mapping ont été testés : bowtie [9] et bwa [10]. Les données d'entrées correspondaient à 11Go de reads à aligner sur un génome de référence de 400Mo. Le lancement de ces analyses avec Hadoopizer comporte plusieurs étapes : (1) Hadoopizer lit un fichier xml contenant la ligne de commande à exécuter et la localisation des données (figure 1) ; (2) les binaires et le génome de référence sont copiés sur chacun des nœuds de calcul ; (3) les reads sont répartis sur les nœuds de calcul par paquets (343 paquets pour 11Go de reads) ; (4) chaque nœud exécute la ligne de commande sur chaque paquet de read reçu (étape de mapping) ; (5) les fichiers de résultats générés pour chaque paquet de reads sur chaque nœud sont regroupés dans un même fichier final de résultat (étape de reducing). Ces premiers tests ont montrés que l'approche proposée permet bien de mettre en œuvre une parallélisation à gros grains sur ce type de données, en se focalisant sur le comportement des programmes vis à vis des données. Par ailleurs, Hadoopizer étant un outil générique, il a été possible de tester différents algorithmes de mapping dans un temps réduit. Figure 1 : Exemple de fichier xml pour un mapping utilisant le logiciel bowtie. Un fichier fastq est automatiquement découpé, le génome de référence est rendu accessible automatiquement sur chaque nœud de calcul, le logiciel a exécuter (bowtie) est déployé par Hadoopizer et les données de sortie sont enregistrées au format SAM. Perspectives : Plusieurs évolutions sont envisagées concernant l'outil Hadoopizer. En particulier, le développement de modules permettant la lecture et l'écriture d'autres formats de données couramment utilisés en bio-informatique (bed, wiggle, gff, blast,...) sera nécessaire. Des modules plus spécialisés pourront aussi être développés pour prendre en charge des modes de parallélisme spécifiques : fenêtres glissantes et chevauchantes sur des séquences ou encore support de données de séquençage pairées. Il est aussi envisagé d'intégrer Hadoopizer à un outil de workflow (slicee [11]). Dans ce cadre, l'utilisateur bio-informaticien pourra ainsi concevoir des workflows pouvant exploiter de façon transparente plusieurs environnements de parallélisme selon les ressources de calcul disponibles : cluster SGE ou cluster Hadoop. En complément à ces développements, ce projet a pour but d'évaluer l'intérêt d'une approche basée sur le cloud en bioinformatique. Des benchmarks seront ainsi réalisés afin de pouvoir comparer de façon objective les performances offertes par cet environnement. Références : [1] Fox. Computer science. Cloud computing--what's in it for me as a scientist?. Science (2011) vol. 331 (6016) pp /88

48 [2] Taylor. An overview of the Hadoop/MapReduce/HBase framework and its current applications in bioinformatics. BMC Bioinformatics (2010) vol. 11 Suppl 12 pp. S1 [3] Nguyen et al. CloudAligner: A fast and full-featured MapReduce based tool for sequence mapping. BMC Res Notes (2011) vol. 4 pp. 171 [4] Schatz. CloudBurst: highly sensitive read mapping with MapReduce. Bioinformatics (2009) vol. 25 (11) pp [5] Contrail [6] Langmead et al. Searching for SNPs with cloud computing. Genome Biol (2009) vol. 10 (11) pp. R134 [7] Langmead et al. Cloud-scale RNA-sequencing differential expression analysis with Myrna. Genome Biology (2010) vol. 11 (8) pp. R83 [8] Jourdren et al. Eoulsan: a cloud computing-based framework facilitating high throughput sequencing analyses. Bioinformatics (2012) vol. 28 (11) pp [9] Langmead et al. Ultrafast and memory-efficient alignment of short DNA sequences to the human genome. Genome Biology (2009) vol. 10 (3) pp. R25 [10] Li et Durbin. Fast and accurate short read alignment with Burrows-Wheeler transform. Bioinformatics (2009) vol. 25 (14) pp [11] Piat et al. SLICEE: A Service oriented middleware for intensive scientific computation. 7th IEEE 2011 World Congress on Services (SERVICES 2011), Washington DC, USA 46/88

49 Instance nationale et multi-communauté de DIRAC pour France Grilles Luisa Arrabito (1), David Bouvet (2), Yonny Cardenas (3), Nicolas Clémentin (4), Hélène Cordier (5), Sophie Gallina (6) Jacques Garnier (7), Pierre Gay (8), Tristan Glatard (9), Vanessa Hamar (10), Claudia Lavalley (11), Gilles Mathieu (12), Sorina Camarasu-Pop (13), Matvey Sapunov (14), Rafael Ferreira da Silva (15), Andrei Tsaregorodtsev (16) (1) (4) (11) Laboratoire Univers et Particules, CNRS/IN2P3, Université de Montpellier II (2) (3) (5) (7) (10) (12) Centre de Calcul, CNRS/IN2P3, Villeurbanne (6) Laboratoire de Génétique et Evolution des Populations Végétales (GEPV), CNRS, Université de Lille 1 (8) pierre.gay@u-bordeaux1.fr, Mésocentre de Calcul Intensif Aquitain (MCIA), Université de Bordeaux 1 (9) tristan.glatard@creatis.insa-lyon.fr, (13) sorina.pop@creatis.insa-lyon.fr, (15) rafael.silva@creatis.insa-lyon.fr, Université de Lyon, CREATIS, CNRS, Inserm, INSA-Lyon, Université Lyon 1 (14) sapunov@cppm.in2p3.fr, (16) atsareg@in2p3.fr, Centre de Physique des Particules de Marseille (CPPM) ; CNRS/IN2P3, Université de la Méditerranée Overview DIRAC [DIRAC] [TSA-08] is a software framework for building distributed computing systems. It was primarily designed for the needs of the LHCb [LHCb] Collaboration, and is now used by many other communities within EGI [EGI] as a primary way of accessing grid resources. In France, dedicated instances of the service have been deployed in different locations to answer specific needs. Building upon this existing expertise, France Grilles [FG] initiated last year a project to deploy a national, multi-community instance in order to share expertise and provide a consistent high-quality service. After describing DIRAC main aims and functionalities, this paper presents the motivations for such a project, as well as the whole organizational and technical process that led to the establishment of a production instance that already serves 13 communities: astro.vo.eu-egee.org, biomed, esr, euasia, gilda, glast.org, prod.vo.eu-eela.eu, superbvo.org, vo.formation.idgrilles.fr, vo.france-asia.org, vo.france-grilles.fr, vo.msfg.fr and vo.mcia.fr. Enjeux scientifiques et opérationnels L une des missions principales de France Grilles est de faciliter l accès aux ressources à ses communautés d utilisateurs, en favorisant l utilisation de services répondant à ce besoin et en participant à leur mise en place. Pour certains outils déjà largement utilisés, France Grilles peut jouer un rôle fédérateur : c est le cas pour le service DIRAC [DIRAC] [TSA-08] : DIRAC est une solution complète permettant à une communauté d'utilisateurs d'accéder à des ressources distribuées de façon optimisée, transparente et fiable. Issu de la communauté de la physique des hautes énergies (HEP), cet outil s'adresse néanmoins aux utilisateurs de toutes les disciplines scientifiques. Le gain apporté par l'utilisation sur des grandes VOs de systèmes par tâches pilotes tel que DIRAC par rapport aux mécanismes de soumission classique tel que glite WMS a été montré à maintes reprises, par exemple dans [MOS-11]. Les ressources accessibles via DIRAC ne sont pas limitées à un intergiciel particulier : en plus de glite [GLITE], des ressources disponibles via ARC [ARC] ou UNICORE [UNI] seront à terme accessibles. DIRAC est aussi conçu pour pouvoir accéder à des ressources non grilles, comme des grappes locales (cela a été par exemple fait pour le KEK computing center au Japon ou le IHEP computing center en Chine) ou des ressources Cloud, notamment celles disponibles sur le cloud académique de France-Grilles : les problèmes spécifiques de réservation des ressources de type cloud en fonction de disponibilité de travaux des utilisateurs sont adressés par l ordonnanceur des machines virtuelles de DIRAC [GRA-11] [MEN- 12]. Ce composant permet d inclure différents types de clouds de façon transparente dans l ensemble des éléments de calcul gerés par DIRAC. Comme évoqué précédemment, DIRAC est déjà largement utilisé par différents partenaires de France Grilles, dans différents contextes. Les cas exposés ci-dessous présentent des exemples de cette utilisation, ainsi que de l intérêt de l outil. Le Laboratoire Univers et Particules de Montpellier (LUPM) est impliqué d une part dans le soutient aux expériences d astroparticules représentées au laboratoire et d autre part dans l administration du site grille MSFG-OPEN. En particulier, les expériences CTA (Cherenkov Telescope Array) [ACT-11] et Fermi [ATW-09] ont des besoins de calcul importants dans le cadre des simulations Monte-Carlo, ayant pour objectif de déterminer les performances des expériences en fonction des conditions expérimentales. Dans ce contexte, il s est avéré nécessaire de disposer d un service comme DIRAC permettant l optimisation de l utilisation des ressources, la gestion des campagnes de simulations et un accès aux ressources simplifié pour les utilisateurs finaux. L évaluation de DIRAC a démarré en avril 2011 dans le cadre des simulations Monte-Carlo de CTA. Une campagne de simulation consiste typiquement en tâches produisant environ 200 TB. Les données produites sont mises à disposition des utilisateurs au travers des modules DIRAC intégrant les codes d analyse de CTA. Dans l'expérience Fermi un système de production (Pipeline) gère de manière centralisée le traitement de données réelles et les simulations Monte-Carlo. Ce système ayant été initialement conçu pour fonctionner sur des fermes de calcul dédiées au SLAC National Accelerator Laboratory (Stanford, Etats-Unis), il a été étendu et est opérationnel depuis quelques années sur la ferme du Centre de Calcul de l IN2P3. Les besoins pressants de calcul liés au "reprocessing" de données ont poussé récemment la collaboration à explorer la possibilité d'étendre ce système à l'utilisation des grilles de calcul, et en particulier 47/88

50 de EGI. Dans ce contexte, l'utilisation de DIRAC pour assurer l'optimisation de la production a été rapidement envisagée. L'interfaçage des services DIRAC et le système initial de Pipeline est actuellement en cours, en particulier pour assurer le transfert des données et de métadonnées permettant la mise à jour en temps réel des catalogues centralisés. Les calculs des simulations Monte-Carlo seront ainsi très probablement transférés sur EGI, avec typiquement entre 4 et 5 productions par an, représentant un nombre total de quelques dizaines de milliers de tâches chacune. Enfin le LUPM dispose également d'une Organisation Virtuelle (VO) locale, vo.msfg.fr. Elle est est destinée aux utilisateurs locaux de la grille, qu'ils soient nouveaux entrants ou utilisateurs n'appartenant à aucune VO officielle. Le fait de disposer d'une VO locale donne une grande souplesse d'utilisation des infrastructures, car l'administrateur du site gère également la VO et peut ainsi faciliter l'accès aux ressources ainsi que la résolution d'éventuelles difficultés de configuration. Dans ce contexte, DIRAC facilite grandement la soumission de tâches grâce à son API de haut niveau. Le site M3PEC (Bordeaux) s'est aussi doté d'une VO locale (vo.mcia.fr) afin de promouvoir l'utilisation de la grille EGI dans le périmètre aquitain. Cette VO est destinée à accueillir des utilisateurs en phase de test ou de portage de leurs applications. DIRAC s'est imposé pour faciliter l'accès aux utilisateurs de cette VO avec la mise en place d'une instance locale. Le laboratoire CREATIS administre une instance DIRAC déployée sur la VO biomed. Cette instance est dédiée aux tâches générées par la plate-forme «Virtual Imaging Platform» (VIP) [VIP] [ISBI-12] dédiée à la simulation médicale. Comme dans de nombreux autres domaines, la simulation numérique révolutionne l'étude des processus médicaux tels que l'acquisition et le traitement d'images médicales, ou le planning de radiothérapie. Des exemples de résultats produits avec VIP concernent la simulation du planning de radio-/protonthérapie [GRE-11] et la simulation réaliste d'images [ALE-12]. Vu le volume de calcul nécessaire, disposer de ressources de calcul en quantités suffisante est critique pour la réalisation de ces simulations. Par exemple, la simulation d'un planning de protonthérapie pour le cancer de la prostate peut demander 2 mois de temps CPU. En production depuis fin 2010, 236 utilisateurs de 27 pays sont désormais enregistrés dans VIP. Environ tâches ont été soumises via DIRAC entre janvier 2011 et avril D'après les statistiques collectées par EGI [ACC], la plate-forme VIP représente environ 10% du temps CPU consommé par la VO biomed sur cette période. Deux services ont été développés spécifiquement en plus de ceux offerts par DIRAC : un service de comptage d'évènements simulés par le logiciel GATE et un service permettant d'obtenir l'état détaillé des tâches de la plate-forme.dans le cadre du projet GISELA [GIS], l application de bio-informatique MyLims [MYLI] permet aux utilisateurs de soumettre des tâches avec un portail web installé à l'université "Del Valle" (UNIVALLE) en Colombie. La soumission est réalisée en deux phases : une soumission locale, nécessaire pour des questions de licences liées au logiciel Moloc, et une soumission grille pour les calculs via le logiciel Gaussian [GAUSS]. Les utilisateurs ont besoin d un même portail web de soumission pour ces deux phases. Pour réaliser ces calculs de manière transparente, un agent a été ajouté dans le WMS de DIRAC. Il contacte le serveur de MyLims et génère automatiquement les tâches d'utilisateurs de DIRAC en fonction du nombre de tâches en attente. Les résultats sont envoyés directement au serveur [TSA-12]. Pour tous ces cas d utilisation, une même expertise du service est nécessaire pour assurer le fonctionnement optimal du système : la configuration, l'administration et l'opération fiable d'un ensemble de services DIRAC sont des tâches qui gagnent à être partagées avec une communauté d'experts. Le projet FG-DIRAC vise à mettre en place une instance nationale du service DIRAC en production, ouverte à plusieurs communautés, et gérée comme un service de l infrastructure de grille nationale France Grilles. Cela répond à plusieurs objectifs : - Optimiser les performances et l utilisation des ressources DIRAC ; - Permettre aux petites communautés de bénéficier d une instance de production ; - Faciliter l accès à la grille pour les nouvelles communautés ; - Coordonner le support et la formation autour de DIRAC ; - Construire et développer une communauté d experts DIRAC ; - Fournir un retour d'expérience aux développeurs DIRAC ; - Mutualiser les efforts et les ressources déjà fournis. Dans le cas de la VO vo.mcia.fr, la participation à l'instance nationale France Grilles a aussi pour but de proposer aux utilisateurs de cette VO un environnement homogène entre la phase de mise au point de leurs applications et le passage en production vers une VO autorisant l'accès à plus de ressources (que ce soit une VO thématique telle que biomed ou la VO nationale vo.france-grilles.fr). Du point de vue de CREATIS, l'utilisation d'une instance DIRAC partagée entre partenaires de France-Grilles devrait par ailleurs permettre de réduire significativement la charge de maintenance et d'administration actuellement nécessaire à CREATIS pour le support de VIP. Développements, utilisation des infrastructures Les serveurs FG-DIRAC sont déployés sur un cluster VMWARE au CC-IN2P3. La distribution logique des services dans les serveurs est la suivante : - ccdirac01 : Master Configuration Server, management de la Sécurité. - ccdirac02 : Workload Management System - ccdirac03 : Data Management System 48/88

51 - ccdirac04 : DIRAC Storage Element - ccdirac05 : portail Web alias -> dirac.france-grilles.fr L architecture matérielle est composée de 2 ESXi (8 cores/72gb) qui font tourner l'ensemble des machines dans un cluster vmware avec Distributed Resource Scheduler (DRS) [DRS], HA (High Availability) [HA] et stockage NFS (Network File System). Cette configuration permettra de gérer jusqu'à tâches grille simultanées. La capacité du système peut être facilement augmentée grâce à l architecture modulaire de l intergiciel DIRAC. Cela permet de déployer les différents services ou même plusieurs instances d un service sur plusieurs serveurs distribués pour répondre à une charge élevée du système. Des tests stressant le système d ordonnancement des tâches de DIRAC ont montré qu une configuration telle que celle de FG-DIRAC est capable de gérer jusqu'à 1 million de tâches par jour. Dans le cas de l installation FG-DIRAC, par exemple, certain services sont déployé ailleurs qu au CC-IN2P3 : au CPPM, Marseille et à CREATIS, Lyon, ce qui ajoute de la redondance et augmente la fiabilité générale du système. L ouverture de l instance FG-DIRAC à différentes communautés est prévue de manière progressive, sur la base des communautés utilisant déjà le service ou disposant d une expertise et d un support dans la gestion du service. A l heure actuelle, les Organisations Virtuelles configurées sur le système sont pour la plupart multidisciplinaires (vo.france-grilles.fr, vo.msfg.fr, vo.mcia.fr, euasia.euasiagrid.org, prod.vo.eu-eela.eu, vo.france-asia.org) ou dédiées à la formation (vo.formation.idgrilles.fr, gilda). Mais le service est également ouvert à des communautés pilotes dans le domaine des sciences de la vie (biomed), de l astrophysique (glast.org et astro.vo.eu-egee.org), des sciences de la terre (esr) et de la physique des hautes énergies (superbvo.org). Outils, organisation et difficultés rencontrées Pour répondre aux objectifs présentés plus haut, le projet FG-DIRAC a été initié comme un partenariat entre France Grilles et plusieurs laboratoires, comme décrit sur la figure 1. La mise en place de l instance nationale FG-DIRAC a été prévue en trois phases, comme décrit dans le tableau 1. M3PEC CC-IN2P3 IN2P3-CPPM CREATIS LUPM Administration du service France Grilles Coordination du projet CC-IN2P3 Hébergement Projet DIRAC Développement Fig. 1. Organisation du projet FG-DIRAC L équipe d administration étant répartie sur 5 sites, la surveillance s effectue en rotations hebdomadaires. La synchronisation entre les équipes est assurée au moyen d une liste de diffusion ainsi que d une section dédiée dans le wiki des opérations France Grilles [FGOP] qui regroupe l ensemble de la documentation nécessaire aux tâches de surveillance. Il est prévu de formaliser la collaboration entre France Grilles et les laboratoires impliqués par le biais d accords, rédigés sous forme de Memorandum of Understanding (MoU), précisant l implication de chaque entité ainsi que les objectifs communs à atteindre. La rédaction d un tel accord pour l hébergement de la plateforme est en cours. La mise en place technique de l instance nationale s étant faite sans difficulté particulière, les principales difficultés rencontrées sont d ordre organisationnel : en particulier, la rédaction d un accord d hébergement n est toujours pas achevée à la date d écriture. Cela est en partie dû aux différentes conditions à préciser, aux accords précis sur la qualité de service, ainsi qu aux modalités et contreparties éventuelles. Bien que ce service soit officiellement au catalogue de France Grilles, ce travail de formalisation reste à terminer pour pouvoir afficher publiquement le niveau de qualité de service nécessaire. 49/88

52 Phase Dates prévisionnelles Objectifs 0. Préliminaire Septembre - Janvier Lancement Février Avril Production A partir de Mai Accords initiaux sur le lancement du projet 2. Accord initial sur l'hébergement de la plateforme 3. Recensement et regroupement des partenaires 4. Définition des communautés d utilisateurs "pilotes" 5. Installation initiale de la plateforme 6. Ouverture de l instance aux communautés pilotes 1. Structuration de la communauté d'administrateurs 2. Mise en place des outils collaboratifs nécessaires à la communauté d administrateurs (forum DIRAC, wiki France-Grilles) et au support des utilisateurs 3. Mise en place et signature d'accords (MoU) pour l'hébergement, l'administration et le support 4. Définition de la feuille de route pour la phase 2 1. Opération pérenne en production 2. Accroissement de la visibilité de DIRAC au sein de la communauté France Grilles 3. Extension de la communauté d'utilisateurs Tableau 1. Phases du projet de mise en place de l instance nationale FG-DIRAC Résultats scientifiques et opérationnels L infrastructure FG-DIRAC est en production depuis mai Les premiers résultats scientifiques concernent l utilisation qui en a été faite par le GEPV (Laboratoire de Génétique & Évolution des Populations végétales), qui utilise l'infrastructure FG- DIRAC pour des 2 thématiques nécessitant de nombreuses simulations et analyses de données : 1) Étudier l'effet du système de reproduction sur la viabilité des populations à partir d'un modèle individu-centré, génétiquement et démographiquement explicite [ABU-12]. 2) Étudier l'efficacité d'une méthode d'analyse Bayésienne pour déterminer la structure hiérarchique de populations à partir du génotype moléculaire des individus [PAU-12]. Les besoins pour ces 2 études concernent principalement des calculs paramétriques, nécessitent un grand nombre de jobs afin d'une part d'explorer une large gamme de paramètres et d'autre part de réaliser des réplicas indispensables pour des approches stochastiques. Les quantités de données utilisées et générées sont faibles. Dans ce contexte, l'utilisation de DIRAC nous a permis de réaliser ces analyses très rapidement, et avec un très faible investissement en temps pour développer pour des scripts perl de soumission de job et récupération de résultats. D un point de vue opérationnel, les figures suivantes montrent quelques statistiques d'utilisation générale. Fig.2. Nombre total de tâches par groupe Fig.3. Jours de CPU par groupe 50/88

53 Plus de jobs utilisateurs ont été envoyés entre le 1 er mai et et le 5 septembre 2012 par environ 25 utilisateurs de 10 VOs. La VO biomed et la VO globale de production prod.vo.eu-eela.eu utilisée sur l infrastructure sud-américaine GISELA [GIS] ayant été les utilisateurs les plus gros utilisateurs. La figure 2 montre la distribution des jobs par groupe DIRAC et le principal utilisateur est un utilisateur de la VO biomed, avec 78% du nombre total de jobs. La figure 3 compare le nombre de jours de CPU utilisés par les groupes DIRAC, et en cohérence avec la figure 2, la plupart des ressources sont utilisées par le groupe biomed_user avec 93.1%. La figure 4 montre le nombre total de tâches exécutées par site entre les semaines 18 et 36 en 2012 et met en évidence que le site irlandais cstcdie qui supporte les deux VOs est le plus gros contributeur sur la période considérée. La figure 5 présente un exemple du nombre de jobs en exécution par site pour les semaines 26 à 36 en Le taux d échecs observé est environ de 7% dont la majorité sont les échecs des applications dus aux erreurs dans la préparation des tâches par les utilisateurs. Le taux d échecs lié à un dysfonctionnement du système FG-DIRAC est estimé à moins de 3%. Fig.4. Nombre total de tâches par site Fig.5. Nombre de tâches par site en fonction du temps Ces premiers résultats opérationnels sont complétés par une action de communication, formation et dissémination menée par France Grilles sur l instance FG-DIRAC mais également sur l outil DIRAC lui-même. Perspectives D un point de vue opérationnel, le gain apporté par la mise en place de FG-DIRAC, sans être pleinement évalué, est déjà visible. La collaboration initiée à travers le projet et notamment la mise en place de rotations pour la surveillance et l administration du système permets déjà la mutualisation de l effort et le partage d expertise évoqués en objectifs. Et s il est prévu que l utilisation de l instance FG-DIRAC soit de plus en plus intensive, l accroissement de l effort nécessaire pour délivrer le service devrait rester minimal. Au sein de la communauté biomed, l'instance nationale DIRAC n'est pour l'instant utilisée que par quelques utilisateurs. Une montée en charge progressive est envisagée, en connectant d'abord les utilisateurs DIRAC existant (CREATIS, I3S), puis en encourageant les nouveaux utilisateurs à utiliser cette instance. L'intérêt principal pour la VO est (i) d'offrir un service de soumission de tâches fiable et performant pour les nouveaux utilisateurs, et (ii) de progressivement harmoniser les mécanismes de soumission de tâches, pour permettre un meilleur contrôle. L ouverture à l international d une instance DIRAC fait également partie des perspectives à moyen terme de France-Grilles., Nous pouvons d ores et déjà mentionner que c est déjà en partie le cas par le biais des communautés GISELA et France- Asia supportées dans l instance FG-DIRAC : Dans le cadre de GISELA, les ressources de calcul sont directement accessibles via les portails DIRAC de 3 sites latinoaméricains en plus de celui de France-Grilles. De plus, les services DIRAC, fournis dans le cadre de la grille latinoaméricaine depuis 2009, sont en cours d intégration à l instance FG-DIRAC ; certains d entre-eux, comme les services auxiliaires de Configuration, sont maintenus sur les sites de GISELA pour assurer la redondance nécessaire. Quant à la communauté Asie-Pacifique, les ressources de calcul de cette région sont progressivement ajoutées dans la configuration du projet FG-DIRAC. Toutefois, les utilisateurs de la région Asie-Pacifique ont déjà accès au portail DIRAC de France-Grilles à travers la VO France-Asia. Les grilles volontaires construites sur la base de la technologie BOINC [BOINC] représentent autre type des ressources potentielles. DIRAC offre le support pour la construction des grilles de ce type. Les grilles basées sur le logiciel des projets de International Desktop Grid Federation (IDGF) [IDGF] peuvent être aussi utilisés. Au-delà de cette montée en charge prévue au niveau des communautés pilotes, il s agit de faire de FG-DIRAC un produit phare du catalogue de services de France Grilles, en le proposant de manière plus large avec une même qualité de service 51/88

54 et de support. DIRAC est en effet un produit qui facilite grandement l accès à la grille, et c est là l une des missions fondamentales de France Grilles. Par ailleurs, la mise en place de FG-DIRAC comme collaboration entre différents partenaires sous la coupe de France Grilles est un excellent précédent, et il est attendu que d autres services bénéficient de l expérience acquise via ce projet d envergure. Références [DIRAC] Projet DIRAC : [TSA-08] A. Tsaregorodtsev et al. DIRAC : a community Grid Solution in J. Phys.: Conf. Ser , 2008 [MOS-11] J.T. Mościcki : Understanding and mastering dynamics in computing grids: processing moldable tasks with userlevel overlay (2011), p. viii, 178 [GRA-11] R. Graciani Diaz, A. Casajus Ramo, A. Carmona Agüero, T. Fifield, M. Sevior : "Belle-DIRAC Setup for Using Amazon Elastic Compute Cloud" In Journal of Grid Computing Volume 9 Issue 1, March 2011 Pages [MEN-12] V.Mendez, V.Fernandez, The Integration of CloudStack and OpenNebula with DIRAC, in Proceedings of the CHEP 2012 International Conference, New-York, May 2012 [LHCb] Collaboration LHCb : [EGI] European Grid Initiative (EGI) : [FG] Groupement d Intérêt Scientifique France Grilles : [GLITE] Intergiciel glite : [ARC] Intergiciel ARC : [UNI] Intergiciel UNICORE : [CTA] Cherenkov Telescope Array (CTA) project : [ACT-11] The CTA Consortium, M. Actis, et al., "Design Concepts for the Cherenkov Telescope Array CTA: an Advanced Facility for Ground-Based High-Energy Gamma-Ray Astronomy", Experimental Astronomy, 32, (2011). [VIP] Plateforme VIP : [ISBI-12] T. Glatard, A. Marion, H. Benoit-Cattin, S. Camarasu-Pop, P. Clarysse, R. Ferreira da Silva, G. Forestier, B. Gibaud, C. Lartizien, H. Liebgott, et al., "Multi-modality image simulation with the virtual imaging platform: Illustration on cardiac MRI and echography", IEEE International Symposium on Biomedical Imaging (ISBI), Barcelona, Spain, [ACC] Portail d accounting EGI : [GRE-11] L. Grevillot, D. Bertrand, F. Dessy, N. Freud, and D. Sarrut. "A Monte Carlo pencil beam scanning model for proton treatment plan simulation using GATE/GEANT4." Physics in Medicine and Biology, 56(16): , 2011 [ALE-12] M. Alessandrini, H. Liebgott, D. Friboulet, and O. Bernard, Highly realistic simulation of echocardiographic image sequences for ground-truth validation of motion estimation. in IEEE ICIP 12, Orlando, [GIS] Grid Initiatives for e-science virtual communities in Europe and Latin America : [MYLI] mylims.org: My Database of spectra and chromatograms: [GAUSS] Logiciel Gaussian : [TSA-12] A. Tsaregorodtsev, V. Hamar. DIRAC experience with porting user applications in GISELA, in Proceedings of the Joint GISELA-CHAIN Conference, R. Barbera et al. (Eds.), COMETA [ATW-09] Atwood et al. The Large Area Telescope on the Fermi Gamma-ray space telescope mission, ApJ , 2009 [DRS] VMware DRS : [HA] VMware HA : [FGOP] Wiki operations France Grilles : [ABU-12] D. Abu Awad et al, "Reproductive strategies, demography and mutational meltdown", Article soumis aux Journées scientifiques Mésocentres et France grilles 1-3 octobre 2012 Paris [PAU-12] M. Pauwels et al, "Détection a posteriori de structure génétique en population hiérarchisée", Article soumis aux Journées scientifiques Mésocentres et France grilles 1-3 octobre 2012 Paris [BOINC] [IDGF] 52/88

55 Distributed Computing for Neurosciences: the N4U Example Niobe Haitas (1), Geneviève Romier (2), Baptiste Grenier (3), Giovanni Frisoni (4), David Manset (5), Richard McClatchey (6), Jérôme Revillard (7), Keith Cover (8), Gabriella Spulber (9), Tristan Glatard (10), Jean- François Mangin (11), Arthur Toga (12), Alan Evans (13) (1) Institut des Grilles et du Cloud, IDGC (2) Institut des Grilles et du Cloud, IDGC (3) maat France, maatg (4) Provincia Lombardo Veneta Ordine Ospedaliero di San Giovanni di Dio- Fatebenefratelli, FBF (5) maat France, maatg (6) University of the West of England, UWE (7) maat France, maatg (8) VU University Medical Center Amsterdam, VUmc (9) Karolinska Institutet, KI (10) Université de Lyon, CREATIS, CNRS, Inserm, INSA-Lyon, Université Lyon 1 (11) jfmangin@gmail.com, Commissariat à l Energie Atomique et aux Energies Alternatives, CEA\CATI (12) toga@loni.ucla.edu, UCLA Laboratory of Neuroimaging (13) alan@bic.mni.mcgill.ca, McGill, CBRAIN Overview Imaging data of people with brain diseases are becoming increasingly available and accessible, leading to the development of computational infrastructures to facilitate scientists access to image databases and e-science services. The N4U (neugrid 4 you) project offers a platform for neuroscientists where they can find core services and resources for brain image analysis, and access datasets, processing pipelines, computational resources, services and support. The N4U platform, available at is based on the previously developed neugrid technology 1 for imaging neuroscientists of Alzheimer s disease (AD) but designed to be adaptable to other user communities. N4U offers tools and associated support and training to process imaging datasets on grid resources. This abstract summarizes some issues related to the processing of neuroimaging data, presents the N4U infrastructure, and the resulting tools, applications and datasets that it offers. Scientific Issues, Computing, Storage and Visualization Needs Neurodegenerative diseases (NDD) such as Alzheimer s, grey matter, white matter and psychiatric diseases affect the brain and are responsible for a large share of disability in the population. For their early diagnosis, preventive and treatment therapies, effective disease-modifying drugs require accurate disease markers. There are no tracking markers to diagnose the disease but diagnosis is traditionally made on clinical grounds and disease progression is monitored through cognitive testing. This lack of objective diagnosis means that the disease cannot be diagnosed at the mildly symptomatic stage and there is huge heterogeneity of diagnostic accuracy within EU countries. Furthermore, clinical trials of drugs to delay the progression of the disease require hundreds of patients followed for many months, resulting in non-optimised drug discovery of efficient drugs. The lack of open data in brain MRI research makes the effort of addressing AD even more challenging (Barkhof 2012). Imaging can detect the changes that take place in the brain of patients with Alzheimer s, multiple sclerosis and psychiatric diseases at the molecular, cellular, tissue and organ levels and therefore, addressing the need for accurate disease markers. Recent advances in neuroimaging demonstrate subtle cognitive alterations that are detectable years prior to the development of objective memory deficit meaning that the disease can be diagnosed much earlier. Modern imaging techniques are essential not only for diagnosing but also for processing and sharing data all over the world. Imaging techniques are computationally intensive, and as such, distributed computing (e.g., grids) are key to addressing the emerging need for user-friendly access to data, analysis pipelines and computational resources as imaging data of people with brain diseases are becoming increasingly available and accessible. These needs have led to the development of computational infrastructures in Europe and North America offering scientists access to the image databases themselves and e-science services, including sophisticated image analysis algorithm pipelines, access to powerful computational resources, visualization and statistical tools. As such, imaging data management has been successfully facilitated by projects such as LONI 2, CBRAIN 3 and DECIDE 4. N4U is meant to be the European counterpart of these platforms /88

56 Infrastructure Development and Use N4U was developed to provide a facilitated e-science environment, a user-friendly Virtual Laboratory, where the broader neuroscience community can find a large range of scientific resources, services, datasets, algorithm applications, intuitive computational resources and support (Frisoni et al. 2011). The N4U platform addresses the needs of neuroscientists who wish to experiment and interact with the most popular pipelines for brain image analysis, benchmark their image analysis pipeline, or share large datasets with colleagues. The N4U architecture is based on the neugrid one, offering direct or facilitated access to large brain image datasets, popular image analysis pipelines, flexible computational resources, users training and support. N4U follows the Service Oriented Architecture (SOA) paradigm. As shown on Figure 1, the N4U Science Gateway consists of two components: a backend, composed by all the Web Services being the ground of the platform with the addition of external applications; a frontend, offering a user friendly web interface allowing user communities to easily interact with the platform. The backend and the fronted are decoupled; it is possible to have multiple frontends accessing the same services with heterogeneous and/or specialized interfaces. N4U platform overview Figure 1: Results and Discussion Although the N4U Science Gateway is not yet finalized, a number of tools, datasets and applications are already available and accessible through the N4U platform. They are briefly described below: The Desktop Fusion offers users access to different tools and facilities (LONI client, an XTerm, a graphical text editor, a file browser). Users only need a Java virtual machine and don t need to install anything on their computer. It also allows users to 54/88

57 upload a shared directory of their local computer inside a folder of the Pandora Gateway, and easily upload content on the grid. Figure 2 shows a screenshot of the main tools available through desktop fusion. Figure 2: screenshot of the tools available in Desktop Fusion The GridBrowser allows users to browse the Logical File Catalog (LFC) and to download or upload files from their computer to the grid. This portlet does not require any special plugin but is a very user-friendly way of interacting with the storage capabilities of the Grid. Users can easily manage their data like with a traditional file manager. BrainBrowser 5 is an externally hosted web-based, 3D visualization tool for neuroimaging. It allows for real time manipulation and analysis of 3D neuroimaging data whether these are pre-calculated maps, or models and data provided by the user in a supported format (such as Minc, Nifti, object files, plain text). Figure 3 shows a screenshot of the BrainBrowser used to visualise cortical thickness from the N4U platform /88

58 Figure 3: screenshot of the BrainBrowser, started from the N4U gateway The LONI pipeline is a graphical workflow management tool where users can find predefined modules to build their own processing pipelines from modules situated in the server library. Expresslane will also soon be available to help users analyse their resources. ExpressLane is a command line submission framework allowing users to easily submit tasks to a computing facility for grids, such as running a given script on multiple scans or datasets and submitting jobs to the DCI only by generating a list of datasets - without knowledge of the underlying job submission system. Two datasets are available, from the European Union AddNeuroMed program and the US-based Alzheimer Disease Neuroimaging Initiative (ADNI). These initiatives provide more than 10,000 multi-centric MRIs of patients with AD. In Cover et al. (2011) we can find an example of the use of the ADNI dataset. Concerning applications, FSL 6 is available through the LONI pipeline to compute partial volume maps such as CSF (celebral spinal fluid), Grey Matter and White Matter from MRI scans. On Figure 4 we can see an example of a result obtained from an FSL pipeline executed with LONI within N4U. Freesurfer 7 is also being integrated /88

59 Figure 4: result of an FSL pipeline executed within N4U Perspectives Given the data deluge in imaging for neurosciences, users need their data to be more accessible, understandable, usable and shareable. Sharing and interoperability need to be developed not only for data but also for anything that connects to the data production and processing including computing tools, applications, methods, software, metadata, workflows across different platforms and even communication (Haitas 2012). In the coming months, the following new applications will be deployed to ease the usage of the N4U platform and provide more tools to the users' communities: Provenance Service building the N4U data atlas data model (Anjum 2011) Persistency Service to populate the Information Services database by interfacing with datasets and data sources integrated into N4U as well with the algorithms, pipelines and toolkits integrated Analysis Services providing a customisable environment for users to conduct their neuroscience analyses using the Provenance, Persistency and DCI Pipeline service The Analysis Services Graphical User Interfaces (GUI) allowing users to query data, specify and execute pipelines and visualize data by interacting with the Analysis services The Virtual Imaging Platform (VIP 8 ) is an openly-accessible web platform for multi-modality image simulation. The user-friendly web interface will be integrated with the N4U infrastructure, allowing users to easily launch predetermined workflows. References Anjum A. et al. Provenance Management for Neuroimaging Workflows in neugrid. International Conference on P2P, Parallel, Grid, Cloud and Internet Computing. IEEE Computer Society, CS Digital Library. DOI Bookmark: (2011) Barkhof F. Making better use of our brain MRI research data. European Radiology 22:7, DOI: /s (2012) Cover K.S. et al. Assessing the reproducibility of the SienaX and Siena brain atrophy measures using the ADNI back-to-back MP-RAGE MRI scans. Psychiatry Research: Neuroimaging. 193:3, , (2011) Frisoni G.B. et al. Virtual Imaging Laboratories for marker discovery in neurodegenerative diseases. Advance online publication Nature Reviews Neurology. Doi /nrneurol (2011) /88

60 Haitas N. How e-science can help to solve pressing societal challenges: fostering a global effort to develop a worldwide e- infrastructure for computational neuroscientists to fight Alzheimer s disease: joint conclusions. Workshop report: 58/88

61 Etude pangénomique des effets cis haplotypiques sur l'expression des gènes dans les monocytes humains Sophie Garnier 1,2, Vinh Truong 1,2, The Cardiogenics Consortium, Tanja Zeller 3, Stefan Blankenberg 3, Willem H. Ouwehand 4,5, François Cambien 1,2, Alison H. Goodall 6,7, David-Alexandre Trégouët 1,2 (1) INSERM UMR_S 937, Paris, France. (2) ICAN Institute for Cardiometabolism And Nutrition, Pierre and Marie Curie University (UPMC, Paris 6), Paris, France. (3) Department of General and Interventional Cardiology, University Heart Center Hamburg, Hamburg, Germany. (4) Human Genetics, Wellcome Trust Sanger Institute, Hinxton, United Kingdom. (5) Department of Haematology, University of Cambridge and National Health Service Blood and Transplant, Cambridge, United Kingdom (6) Department of Cardiovascular Sciences, University of Leicester, Leicester, United Kingdom. (7) National Institute for Health Research Biomedical Research Unit in Cardiovascular Disease, Glenfield Hospital, Leicester, United Kingdom. Overview: This project aims at assessing whether gene expression variability could be influenced by the presence of more than one proximal (eg cis-acting) single nucleotide polymorphisms (SNPs). In contrast to most previous studies looking at single SNP associations, we focused on the influence of several SNPs through additive or more complex haplotype combinations and undertook a systematic search of cis acting haplotypes expression quantitative trait loci (eqtl) on the entire human genome. This strategy required the analysis of more than 2 billion haplotypic combinations. Our local cluster was not suitable to run this project in a timely manner and large computing resources were needed. We therefore took advantage of the power of the European grid (EGI) to run all the statistical analyses. Our results demonstrated that the monocyte expressions of a substantial proportion of the human genes were under the influence of multiple cis-acting SNPs. About 75% of the detected genetic effects were related to independent additive SNP effects and the last quarter due to more complex haplotype effects. Of note, twenty-four of the genes identified to be affected by multiple cis esnps have been previously reported to reside at disease-associated loci. This could suggest that such multiple locus-specific genetic effects could contribute to the susceptibility to human diseases. Enjeux scientifiques, besoin en calcul, stockage et visualisation : De nombreux travaux récents ont montré que le niveau d'expression d'un gène peut être influencé par des polymorphismes génétiques ("SNPs" pour Single Nucleotide Polymorphisms) situés à sa proximité ("cis esnps"), certains de ces polymorphismes pouvant également être associés à un phénotype comme un risque de maladie ou la variabilité de traits quantitatifs [1-6]. La majorité des études portant sur ces effets cis ne se base cependant que sur l'influence d'un seul SNP sur le gène alors que de manière générale de nombreux SNPs situés en cis peuvent être impliqués dans la variabilité de son expression. Les effets de chaque SNP sont parfois indépendants et dans ce cas là, une approche SNP à SNP est pertinente. Ce n'est cependant pas toujours le cas. Non seulement, il faut pouvoir distinguer les vrais effets des SNPs des effets qui seraient dus à un phénomène de dépendance entre deux SNPs (déséquilibre de liaison) mais il faut aussi pouvoir dissocier, lorsque les SNPs ne sont pas indépendants, les effets additifs d effets plus complexes (parfois dus à l influence d un haplotype particulier). Dans ce cas, seules les études considérant plusieurs SNPs, les études haplotypiques [7], sont pertinentes. Dans ce projet, nous avons utilisé une approche dite haplotypique, qui permet d'analyser l'effet d'un groupe de SNPs sur l expression d'un gène et, pour la première fois, cette étude a été menée de manière systématique sur l'ensemble du génome humain. Pour cela, nous avons utilisé les données de l'étude Cardiogenics ([11]), un projet européen dans lequel 758 individus ont été génotypés pour environ SNPs et pour lequel l expression des gènes a également été mesurée. Le tableau 1 donne les principales caractéristiques de cette étude. Notons que les sondes sont utilisées pour mesurer le niveau d'expression d'un gène. Le nombre de sondes est plus élevé que celui des gènes car l'expression d'un gène peut être mesurée par plusieurs sondes. 59/88

62 Nombre d'individus 758 Nombre de SNPs Nombre de gènes concernés Nombre de sondes Nombre d'analyses Tableau 1 : Caractéristiques du projet Cardiogenics Une analyse haplotypique pour un gène donné nécessite de prendre en compte toutes les combinaisons possibles entre les SNPs et d'étudier leurs effets sur l'expression du gène. En pratique, nous avons limité à 4 le nombre maximum de SNPs par haplotype en considérant des fenêtres de 30 SNPs. Par exemple, un ensemble de 70 SNPs engendre avec une telle stratégie combinaisons. Pour ce projet, nous avons analyser plus de 2 milliards de combinaisons. L analyse de l expression d un gène pour une sonde dure de quelques secondes à plusieurs minutes selon le nombre de SNPs à étudier au sein du gène. En considérant qu'elle dure 3 secondes, il aurait alors fallu plus de 10 ans pour finir le projet sur un seul CPU. L'ensemble des analyses étant indépendantes entre elles, nous avons commencé à utiliser un cluster en exploitant l'ensemble des ressources (une vingtaine de CPUs). Mais cette solution ne nous permettait pas de finir le projet dans un temps raisonnable. Nous avons ainsi décidé d utiliser une grille de calcul pour terminer nos expériences en quelques mois. Développements, utilisation des infrastructures : L'ensemble des expériences a été conduit sur la grille de calcul européenne EGI (European Grid Infrastructure) avec biomed comme organisation virtuelle. L'utilisation de la grille nous a permis d'accéder à la puissance de calcul nécessaire pour terminer le projet en moins d'un an. L'ensemble de nos expériences a finalement duré environ 8 mois. L'ensemble des tests d'association a été réalisé avec le programme combinhaplo [7]. Nous pouvons noter que ce logiciel est intégré à GridHaplo avec l'interface Easy-gLite [10], qui a été conçu pour lancer ces calculs sur une grille de calcul. Cet outil a déjà été utilisé avec succès pour faire une recherche d'association sur le génome entier entre un ensemble de SNPs et la maladie d'alzheimer [9]. Contrairement à cette précédente étude, notre projet s'intéresse à plusieurs phénotypes (l'expression des gènes) et aux SNPs se trouvant à proximité de chaque gène. GridHaplo nous a semblé moins adapté pour notre projet et avons donc développé nos propres scripts en Python que l'on va décrire succinctement. Nous avons préalablement générer des fichiers pour chacune des sondes qui contiennent le niveau d'expression mesuré par la sonde ainsi que les allèles des SNPs se trouvant à proximité du gène. combinhaplo génère une liste indicée de combinaisons de façon déterministe et peut exécuter les tests d'association pour un sous-ensemble de combinaisons en spécifiant uniquement les indices correspondantes. Nous avons exploité cette caractéristique pour spécifier des blocs de combinaisons à tester. Le script principal permet de faire exécuter une série de tests sur la grille de calcul. Elle exécute les étapes suivantes: sélectionner une sonde définir les blocs de combinaisons à tester spécifier les tâches à soumettre à la grille de calcul (génération automatique des fichiers jdl) soumettre les tâches à la grille Une tâche correspond donc à un ensemble de tests d'association à exécuter. Pour ce projet, nous avons considéré au maximum 4500 tests par tâche. Ce nombre a été fixé empiriquement pour que la tâche puisse s'exécuter pendant la durée du proxy (c'est à dire 24h par défaut). Cependant, cela a impliqué un nombre conséquent de tâches à gérer sur la grille. Nous avons donc été obligés de les soumettre automatiquement et à espace régulier. Un certain nombre de tâches n'ayant pas pu s'exécuter correctement, il nous a fallu concevoir des scripts permettant de vérifier l'intégrité et l'intégralité des fichiers résultats, de spécifier les blocs de combinaisons (et la probe associée) qui ont posé problème et de soumettre ces nouvelles tâches. Les fichiers résultats correctement générés ont ensuite été transférés 60/88

63 sur le cluster local pour traiter les données. Outils, le cas échéant complémentarité des ressources, difficultés rencontrées : Notre approche consiste à soumettre un grand nombre de jobs en automatisant le plus possible les différentes étapes. Une attention particulière a été faite pour ne pas noyer un élément de calcul sous un grand nombre de tâches. A chaque soumission, nous avons uniquement regardé les CE qui n'ont pas de tâches en attente et qui ont plus de 10 processeurs disponibles. Cette stratégie a permis d exécuter un grand nombre de tâches soumises. De plus, pour des raisons diverses, des éléments de calcul (CE) de la grille n'arrivaient pas à exécuter les tâches demandées. L'une des causes venait du système d'exploitation utilisé par les CE. Nous avons en effet utilisé une version compilée sous linux de combin_haplo. Malheureusement, nous n'avons pas identifié toutes les causes de ces échecs. Pour contourner ce problème, nous avons utilisé une solution simple : nous avons spécifié une liste noire de CE. Nous avons ainsi écarté 54 CE. De plus, la gestion des proxys n'a pas été facile. Contrairement à d'autres travaux, nous n'avions pas réussi à utiliser les proxys de longues durées ou leurs renouvellements automatiques. En effet, de telles fonctionnalités peuvent représenter pour certaines VO des faiblesses au niveau de la sécurité de la grille. C'était, semble-il, le cas pour la VO biomed lorsque nous avons exploité la grille. Les proxys ont dû être générés régulièrement à la main. Cette contrainte a particulièrement compliqué la gestion et l'exécution des différentes tâches. Résultats scientifiques : Nous avons réalisé une approche haplotypique sur les données de Cardiogenics à la recherche de groupe de SNPs pouvant influer sur l'expression d'un gène à proximité. Comme nous nous intéressons à des effets dus à de multiples SNPs, nous avons fait une analyse SNP à SNP et sélectionné les sondes et les SNPs dont l'effet haplotypique est meilleur que l'effet d'un seul SNP. Cette phase a permis de retenir 13,4 % des sondes (2650). Une phase de réplication a permis de confirmer une partie de ces résultats (une centaine de sondes). Au final, notre étude montre que l'expression d'un grand nombre de gènes peut être influencée par plusieurs SNPs à travers soit des effets additifs soit des effets plus complexes. Il est donc important de prendre en compte ce type de phénomène avant de se lancer dans des expériences expressions fonctionnelles. Perspectives : Une partie des sondes,dont les expressions ont été trouvées influencées par plusieurs SNPs dans notre projet, ont été rapportées dans la littérature comme associées à des risques de maladie ou à des traits quantitatifs [8]. Ces résultats suggèrent donc que des effets haplotypiques pourraient également contribuer au risque de maladie. Nous nous sommes limités à des haplotypes comportant au plus 4 SNPs or il peut exister des effets cis dus à des haplotypes de taille plus importante. Une recherche systématique paraît cependant difficile, même avec l'utilisation d'une grille de calcul. En effet, le nombre de combinaisons augmente exponentiellement avec le nombre de SNPs. Cela dit, une recherche plus localisée sur des gènes candidats pourrait être envisagée. 61/88

64 Références : [1] Goring HH, Curran JE, Johnson MP, Dyer TD, Charlesworth J, et al. (2007) Discovery of expression QTLs using largescale transcriptional profiling in human lymphocytes. Nat Genet 39: [2] Dixon AL, Liang L, Moffatt MF, Chen W, Heath S, et al. (2007) A genome-wide association study of global gene expression. Nat Genet 39: [3] Stranger BE, Nica AC, Forrest MS, Dimas A, Bird CP, et al. (2007) Population genomics of human gene expression. Nat Genet 39: [4] Emilsson V, Thorleifsson G, Zhang B, Leonardson AS, Zink F, et al. (2008) Genetics of gene expression and its effect on disease. Nature 452: [5] Schadt EE, Molony C, Chudin E, Hao K, Yang X, et al. (2008) Mapping the genetic architecture of gene expression in human liver. PLoS Biol 6: e107. [6] Zeller T, Wild P, Szymczak S, Rotival M, Schillert A, et al. (2010) Genetics and beyond--the transcriptome of human monocytes and disease susceptibility. PLoS One 5: e [7] Tregouet DA, Konig IR, Erdmann J, Munteanu A, Braund PS, et al. (2009) Genome-wide haplotype association study identifies the SLC22A3-LPAL2-LPA gene cluster as a risk locus for coronary artery disease. Nat Genet 41: [8] Hindorff LA, Sethupathy P, Junkins HA, Ramos EM, Mehta JP, et al. (2009) Potential etiologic and functional implications of genome-wide association loci for human diseases and traits. Proc Natl Acad Sci U S A 106: [9] Lambert J-C, Grenier-Boley B, et al (2012) Genome-wide haplotype association study identifies the FRMD4A gene as a risk locus for Alzheimer's disease, Molecular Psychiatry [10] [11] 62/88

65 Un service distribué sur le cloud pour l exécution de chaînes de traitements sur la grille Tristan Glatard Université de Lyon, CREATIS ; CNRS UMR5220 ; Inserm U1044 ; INSA-Lyon ; Université Lyon 1, France glatard@creatis.insa-lyon.fr Overview L utilisation en production de plate-formes d applications utilisant la grille demande des fonctionnalités toujours plus avancées concernant la description des applications [4], leur tolérance aux pannes [1] et l optimisation de leur performance. Les gestionnaires de chaînes de traitements (workflows) en fournissent certaines, mais les services d exécution associés doivent être distribués pour garantir le passage à l échelle et réduire la dépendance à un point unique de défaillance. La distribution par services redondants, invoqués par round-robin, est très sensible aux pannes et nécessite une connaissance à priori des ressources et de leur caractéristiques. Nous proposons un système en pool auquel les gestionnaires de chaînes de traitements contribuent dynamiquement en fonction de leur performance et de leur état fonctionnel. Les gestionnaires sont déployés sur l infrastructure cloud offerte par le projet StratusLab. Des expériences montrent la robustesse et le passage à l échelle de l approche proposée. A terme, une adaptation dynamique du nombre de gestionnaires en fonction de la charge de la plate-forme est envisageable. La mise en production du système dans la Virtual Imaging Platform (VIP [2]) est en cours. Méthode et implémentation La distribution par services redondants, invoqués par round-robin, est très sensible aux pannes. Considérons par exemple le cas d une interface utilisateur de l intergiciel glite, sur laquelle 3 meta-ordonnanceurs (Workload Management Systems - WMS) sont configurés. Lorsque les 3 services sont fonctionnels, leur invocation en round-robin permet effectivement de distribuer la charge. En revanche, dès lors qu un des services disfonctionne, un tiers des soumissions de tâches échoue faute de gestion appropriée des pannes. De même, l invocation en round-robin ne permet pas de contrôler la charge imposée sur un WMS s il vient à être surchargé. Ce problème, illustré ici sur l exécution de tâches, est transposable à l exécution de chaînes de traitements. Pour améliorer la tolérance aux pannes et le contrôle de la charge des services, nous proposons l architecture décrite sur la Figure 1 pour distribuer les services d exécution de chaînes de traitements. Cette architecture est similaire à celle utilisée par les systèmes d exécution de tâches par pilot jobs. Le système est composé d un pool central, auquel les clients peuvent soumettre des chaînes de traitements, suivre leur état, et récupérer leurs résultats. Les chaînes de traitements et leur dépendances sont groupées dans des bundles, annotés sémantiquement comme décrit dans [5]. Des agents, aussi appelés workflow executors, sont distribués et peuvent se connecter au pool, récupérer des chaînes de traitement à exécuter, lancer des moteurs d exécution de chaînes de traitements, envoyer l état des chaînes de traitements au pool et au clients, et transférer les résultats au pool. L état des chaînes de traitements est maintenu à la fois par le pool et par l agent, comme indiqué sur la Figure 2. Quand une chaîne de traitement est soumise, le pool lui assigne l état PENDING. Le pool diffuse périodiquement un message contenant la liste des chaînes de traitements dans l état PENDING pour que les nouveaux agents soient informés. Un délai d expiration peut être associé à l état PENDING. Il expire lorsqu aucun agent n est en mesure d exécuter la chaîne de traitement, par exemple en cas de forte charge. La chaîne de traitement est alors mise dans l état KILLED. Si des demandes d exécution sont faites par les agents, alors le pool sélectionne un agent, lui envoie la chaîne de traitements, et la met en état SENDING. La chaîne de traitements est alors transférées à l agent sélectionné, et mise dans l état SENT, ou FAILED si le transfert échoue. Un délai d expiration (T sent ) est démarré pour détecter les chaînes de traitements bloquées dans cet état. S il expire avant que l agent n envoie un message d état RUNNING, alors la chaîne de traitement est mise dans l état KILLED. Lorsque la chaîne de traitements s exécute, le pool attend des mises à jour d états de la part de l agent jusqu à atteindre l état FINISHED ou FAILED. La connexion avec l agent est aussi testée périodiquement. Si elle est perdue, la chaîne de traitements est mise dans l état KILLED après un délai d expiration. Lorsqu un agent reçoit un message d état PENDING, il vérifie le nombre de chaînes de traitements en cours d exécution puis, si les conditions sont réunies, sélectionne aléatoirement une chaîne de traitement dans le message d état, pour éviter les problèmes de concurrence entre les agents. La vérification du nombre de chaînes de traitements en cours d exécution permet à l agent de contrôler lui-même la charge qui lui est imposée. L agent met alors la chaîne de traitement dans l état WAITING, la demande au pool et démarre un délai d expiration (T waiting ). Si ce délai expire, par exemple si le pool attribue l exécution à un autre agent, alors l exécution est supprimée. Sinon, la chaîne de traitements est mise dans l état LAUNCHING et un moteur 1 63/88

66 Fig. 1: Architecture du service distribué d exécution de chaînes de traitements. La numérotation décrit les étapes de l exécution d une chaîne de traitements. Les flèches terminées par des cercles correspondent à des diffusions larges (broadcast. d exécution est déclenché. Un délai d expiration (T launching ) est armé pour le cas où le moteur ne démarrerait pas. L état de la chaîne de traitement est alors mis à jour jusqu à sa complétion ou son échec. L agent tue aussi les chaînes de traitements en cours d exécution lorsque leur moteur ne répond plus après un délai d expiration T engine crashed. Un prototype de pool, agent et client a été implémenté en Java. Le protocole XMPP (Extensible Messaging and Presence Protocol 1 ) a été utilisé pour la couche de communication du fait de sa capacité à permettre la communication en environnement distribué sans nécessiter de connectivité entrante. Seul le serveur XMPP doit avoir un port ouvert. L API Java smack 2 v3.2.2 a été utilisée. Le pool et l agent ont chacun 3 threads pour recevoir et traiter les messages, pour transférer les fichiers, et pour suivre les délais d expiration. Des bases de données assurent la persistance des états pour permettre au pool et à l agent de redémarrer sans impact sur les chaînes de traitements actives. Une interface Java utilisant JSPF (Java Simple Plugin Framework 3 ) est fournie pour permettre le développement des plugins. Elle a deux méthodes, pour lancer l exécution des chaînes de traitements et récupérer leurs résultats. Un plugin agent a été développé pour les gestionnaires de chaînes de traitements MOTEUR [3] et Triana [6]. Expériences sur le cloud et résultats Deux expériences sont rapportées ici pour étudier le passage à l échelle et la robustesse de l architecture proposée. La version 0.7 du pool de l agent, du client et du plugin MOTEUR, disponible en ligne 4, est utilisée pour ces expériences. Pour chacune de ces expériences, le pool et le clients sont déployés sur des machines différentes, sur le même réseau que le serveur XMPP. Les agents et les moteurs d exécution sont déployés sur l infrastructure cloud mise à disposition par le projet StratusLab 5. Nous utilisons une machine virtuelle (VM) Fedora Core 16 x86 64 contenant Java, MySQL et notre agent. Des comptes XMPP sont créés manuellement pour les agents, et les noms d utilisateurs et mots de passe sont configurés dans les VM déployées avant le démarrage des expériences. Les VMs sont déployées sur le site StratusLab du Laboratoire de l Accélérateur Linéaire à Paris, avant le démarrage des expériences. Les délais d expiration sont de T sent =30 s, T agent lost =10 s, T engine crashed =3 s, et T waiting = T launching =5 s. Le nombre maximum d exécutions par agent est de 3. Le pool est configuré pour diffuser les messages d état PENDING toutes les min(5s + n 0.1s, 300s), où n est le nombre de chaînes de traitements dans l état PENDING. Le passage à l échelle est testé en terme de nombre d exécutions de chaînes de traitements (Exp1-a) et de nombre d agents (Exp1-b). Dans les deux cas, une chaîne de traitements MOTEUR constituée d une seule activité dormant pendant 1 minute est utilisée. Les chaînes de traitements sont soumises séquentiellement au pool. Trois répétitions sont effectuées dans chacun des cas. Pour chaque répétition, le temps total de soumission et le makespan (durée entre le début de la soumission de la première chaîne de traitements et la fin de l exécution de la dernière) sont mesurés /88

67 Client submits workflow bundle Agent sends Waiting message; pool sends bundle to agent Bundle transfer failed Failed Agent updates status Pending Sending Bundle sent Sent Agent updates status Agent updates status Running Finished T sent T agent_lost T pending Killed Pool sets bundle status to PENDING, language is supported, and max active bundles is not reached Pool updates status Pool sends SENDING message Engine updates status Failed Engine updates status Waiting Sending Agent receives bundle and launches engine. Launching Engine updates status Running Finished T engine_crashed or pool killed bundle T waiting T launching Killed (a) Dans le pool (b) Dans l agent Fig. 2: Automates d état des chaînes de traitements. Les états initiaux et terminaux sont indiqués par des cercles. T indique un délai d expiration (timeout). Test Flapping Crash #Killed Makespan(s) #Killed Makespan(s) #Killed Makespan(s) # # # # # # # # # Tab. 1: Robustness of the execution pool to flapping and crashed agents. Pour Exp1-a, 10 agents sont déployés, et le débit maximal est donc de 30 chaînes de traitements par minute (10 agents déployés, chacun pouvant exécuter 3 chaînes de traitement simultanément). Le nombre de chaînes de traitements exécutées varie de 10 à 150 par pas de 10. La Figure 3a montre l évolution du makespan et du temps de soumission par rapport au nombre d exécutions concurrentes. Les droites de régression aux moindres carrés sont aussi tracées. Le temps de soumission et le makespan sont tous les deux poches de leur droite de régression, ce qui indique le bon passage à l échelle du système. La variabilité entre les répétitions est faible. Le temps de soumission est principalement contraint par le temps de transfert des chaînes de traitements (3.6 Ko), pénalisé par l encodage base 64 utilisé par XMPP pour les fichiers. La droite de régression du makespan a une pente inverse de 27,5 exécutions par minute, ce qui est proche du débit maximal sur l infrastructure déployée. Pour Exp1-b, le nombre d exécutions est de 150 et le nombre d agents varie de 1 à 10 par pas de 1. La Figure 3b montre l évolution du temps de soumission et du facteur d accélération en fonction du nombre d agents déployés. Ce est calculé comme le rapport entre le temps cumulé d exécution des chaînes de traitement (150 minutes) et le makespan. Comme attendu, le temps de soumission est stable. Les accélérations mesurées sont correctement approximées par leur droite de régression, ce qui indique que le surcoût du système reste contrôlé. La pente de la droite de régression est de 2,21 et l accélération médiane pour 1 agent est de 2,6. La fiabilité du système vis à vis des pannes survenant sur les agents est testée dans deux configurations : flapping et crash. Dans les deux cas, deux agents sont déployés. Dans la configuration flapping, la robustesse à la perte temporaire de connexion est testée. Un des agents se comporte normalement, et le second se déconnecte du pool pendant 5 secondes toutes les 10 secondes. Dans la configuration crash, les deux agents se comportent correctement pendant les premières 90 secondes, puis un agent se déconnecte jusqu à la fin de l expérience. Le makespan et le nombre d exécutions échouées est mesuré dans les deux cas, et dans une configuration témoin où tous les agents se comportent normalement. La table 1 présente les résultats. Comme prévu, le système est totalement robuste à la configuration flapping. Le crash d un agent n a qu un impact limité sur le système. Seules les chaînes de traitement en cours d exécution au moment de la panne (3 dans notre cas) sont touchées, sans conséquence sur les exécutions ultérieures. Le makespan augmente par rapport à la configuration témoin du fait de la présence d un seul agent après le crash. 3 65/88

68 Conclusion et perspectives L architecture proposée distribue l exécution de chaînes de traitements entre plusieurs agents, par une approche similaire à celle utilisée par les pilot jobs pour la soumission de tâches. Le système résultant est robuste aux pannes des agents, et passe correctement à l échelle. Les agents contrôlent eux-mêmes la charge qui leur est imposée. L infrastructure cloud est appropriée au déploiement d agents, ce que nous avons illustré en déployant nos agents sur un site de l infrastructure StratusLab. A court terme, une mise en production du système présenté ici dans la plate-forme VIP 6 est envisagée. Au delà des fonctionalités présentées plus haut, le pool permettra de gérer une file d attente de chaînes de traitements en cas de saturation du système. A plus long terme, une étude du déploiement automatique d agents sur le cloud en fonction de la charge de la plate-forme est envisagée. Le cloud serait en effet particulièrement adaptée à un déploiement élastique d agents en fonction de la charge courante de la plate-forme. Remerciements Ce travail est financé par le projet SHIWA (numéro ), subventionné par l accord de consortium de l appel INFRASTRUCTURES du 7ème PCRD de la commission européenne. Nous remercions le projet StratusLab pour l infrastructure cloud et le support utilisateurs. Références [1] R. Ferreira da Silva, T. Glatard, and F. Desprez. Self-healing of operational workflow incidents on distributed computing infrastructures. In 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing - CCGrid 2012, pages , Ottawa, Canada, 05/ [2] T. Glatard, A. Marion, H. Benoit-Cattin, S. Camarasu-Pop, P. Clarysse, R. Ferreira da Silva, G. Forestier, B. Gibaud, C. Lartizien, H. Liebgott, K. Moulin, and D. Friboulet. Multi-modality image simulation with the virtual imaging platform : Illustration on cardiac mri and echography. In IEEE International Symposium on Biomedical Imaging (ISBI), Barcelona, Spain, [3] T. Glatard, J. Montagnat, D. Lingrand, and X. Pennec. Flexible and efficient workflow deployment of data-intensive applications on grids with MOTEUR. Int. J. High Perform. Comput. Appl., 22 : , August [4] K. Plankensteiner, J. Montagnat, and R. Prodan. IWIR : a language enabling portability across grid workflow systems. In Proceedings of the 6th workshop on Workflows in support of large-scale science, WORKS 11, pages , New York, NY, USA, ACM. [5] I. Taylor, A. Harrison, D. Rogers, I. Harvey, and A. Jones. Object reuse and exchange for publishing and sharing workflows. In Workshop on Workflows in Support of Large-Scale Science(WORKS 11), Seattle, USA, Nov [6] I. Taylor, M. Shields, I. Wang, and A. Harrison. Visual Grid Workflow in Triana. Journal of Grid Computing, 3(3-4) : , September Submission time Makespan Time (min) Submission time (min) Speed-up Number of bundles (a) Exp1-a : en fonction du nombre d exécution concurrentes Submission time Speed-up Number of agents (1 agent has 3 engines) (b) Exp1-b : en fonction du nombre d agents Fig. 3: Evaluation du passage à l échelle de l architecture en pool. 4 66/88

69 PLATE-FORME RunMyCode G. COLLETAZ, C; HURLIN, C.PERIGNON, V. STODDEN, Y. STROPPA, LEO, Université d'orléans LEO, Université d'orléans GREGHEC, HEC(Paris) Columbia New-York LEO,CNRS, INSHS Overview: RunMyCode is a web service allowing people to run computer codes associated with a scientific publication (articles and working papers) using their own data and parameter values. The service only requires a web browser as all calculations are done on a dedicated cloud computer. Once the results are ready, they are automatically displayed to the user. RunMyCode is a non-for-profit scientific website founded by academics and funded by several national research agencies and universities. The goal of the website is to make academic research easier to use and to replicate. RunMyCode relies on the concept of a paper's companion website. Figure 1: représentation globale de l'architecture RunMyCode Enjeux scientifiques, besoin en calcul, stockage et visualisation : Les objectifs de la plate-forme sont : permettre aux chercheurs français et étrangers de diffuser de façon rapide à l échelle internationale les résultats de leurs recherches à partir d un site centralisant des ressources informatiques de calcul et de traitement, disponibles en ligne. Ce service devrait notamment permettre d augmenter le potentiel de citations de certains articles scientifiques. Offrir à une très large communauté d utilisateurs, qui dépasse largement la seule communauté académique, la possibilité d utiliser, en ligne et de façon interactive, des méthodes de calcul et de traitement scientifiques parmi les plus récentes pour leurs propres données et avec leurs propres choix de paramètres. Cette utilisation n était jusque là pas possible pour l ensemble des utilisateurs qui ne possédaient pas les compétences informatiques pour implémenter ces méthodes sur des progiciels dédiés. Fournir à la communauté académique (chercheurs, éditeurs, arbitres, etc.) un moyen de pouvoir répliquer les résultats scientifiques et d en démontrer ainsi l exactitude, la fiabilité et la portée générale. 1 67/88

70 L architecture de RunMyCode est de type MOM (Middleware Oriented Messages), elle est organisée en deux parties : une partie frontale et une partie Backend. La communication entre les deux parties se fait principalement par envoi de messages et de façon asynchrone. Chaque message envoyé par l application CompanionsSite à la partie Backend contient tous les paramètres nécessaires pour le calcul. La partie Backend contient l ensemble des solveurs et le contexte d exécution (Pré et post-traitement sous Perl) associé à chaque site Compagnon. Elle reçoit le message et le traite jusqu à la récupération par le frontal du fichier résultat. Les besoins de calculs (en temps CPU, en espace de stockage et en quantité mémoire) sont variables en fonction des sites sur lesquels les internautes interagissent et sont conditionnés par les caractéristiques des files d attentes définies au sein des centres de calculs. Le module supplémentaire nommé DTM (Distributed Task Manager) permet de stocker l ensemble des demandes dans une file d attente spécifique et de les consommer à flux maitrisé par l activation d agents résidents sur l infrastructure de calcul. Ce système permet une consommation limitée des ressources. De plus, un mécanisme de cache (sous IRODS) permet avant toute exécution de vérifier si le résultat demandé a déjà été calculé. Dans ce cas et si l auteur du site l a autorisé, le résultat est restitué à l internaute. La visualisation des résultats de calculs est actuellement obtenue sous forme de fichier pdf, une version est à l'étude pour visualiser directement dans le navigateur les résultats en web 2.0 (plus grande interaction). RunMyCode apporte en plus du concept site compagnon à une publication ou un working paper le concept de site thématique qui permet aux internautes (à la communauté scientifique) de disposer de moyen d'exécution sur plusieurs moteurs de calculs (plusieurs sites compagnons) avec un concept de Map-Reduce avancé pour s appuyer pleinement sur une architecture distribuée. Illustration d une demande de soumission simple Frontal RunMyCode 1 Demande Outils de soumission DTM/SGE Worker Worker Résultat pdf DataGrid(IRODS) Illustration d une demande de soumission dans le cadre d un site thématique/ro (Recherche opérationnelle) Phase de SPLIT Phase de MAP Phase de REDUCE Demande 1/Data 1 Exécution 1/Data 1 1 Demande Demande 2/Data 2 Exécution 2/Data 2 Exécution reduce Demande 3/Data 3 Exécution 3/Data 3 Demande n/data n Exécution n/data n La phase de split a lieu dans le cadre de site RO, car les paramètres fournis par l utilisateur sont des expressions (exemple sur Matlab 0 :1 :10 ce qui indique que le paramètre doit varier par pas de 1 de 0 à 10) En résumé : la plate-forme peut traiter des demandes Un jeu d inputs avec un solveur Un jeu d inputs avec plusieurs solveurs Plusieurs jeux d inputs avec un solveur Plusieurs jeux d inputs avec plusieurs solveurs 2 68/88

71 Développements, utilisation des infrastructures : Situation actuelle : Depuis fin 2010, le développement de la plate-forme a été réalisé au sein laboratoire LEO UMR7322 par l'équipe RMC'LABS.en collaboration avec l équipe du CCIN2P3 à Lyon et du TGE-ADONIS. La plate-forme à ce jour est opérationnelle et permet aux chercheurs de constituer leurs sites Companions et à l équipe RunMyCode de les intégrer. Actuellement plus de 60 Sites Companions sont disponibles et couvre deux champs disciplinaires l ECO-Gestion et les Mathématiques (traitement d images). Développement : RMC'LABS en collaboration avec les autres membres du projet, défini et développe les différentes applications aussi bien au niveau du frontal (partie WEB) que de la partie backend (logistique, traitement et exécution des tâches). Les applications sont développées sous l'environnement J2EE et s'exécutent sous TOMCAT. La plate-forme est abritée sous l'infrastructure mutualisée du TGE-Adonis (INSHS) Elle s'appuie sur un processus de gestion de tâches DTM (Distributed Task Manager) qui permet aux applications Tomcat de soumettre des demandes d exécution sur les serveurs de calculs Cette mise en place et ces choix techniques permettent d'envisager un couplage de plusieurs centres de calculs afin d'étendre l'offre de calculs de RunMyCode. Un couplage est en phase de prototypage avec le centre de calculs d'orléans CCSC (opérationnelle en Octobre 2012). Frontal Web Site Orléans (CCSC) Site Lyon Backend/SGE Backend/SGE IRODS Des développements sont élaborés conjointement avec plusieurs structures telles que le LI de Tours (Laboratoire Informatique) et l'efrei (Ecole d'ingénieurs Villejuif).Ces partenaires contribuent dans l'exploration de solution permettant de répondre aux nombreuses problématiques que soulève ce projet. 3 69/88

72 Outils, le cas échéant complémentarité des ressources, difficultés rencontrées : Un ensemble d'outils est mis en place afin de permettre une grande robustesse de la plate-forme RunMyCode. Parmi ces outils on peut citer ActiveMQ et MongoDB qui devraient permettre la mise en place d'une logistique calcul beaucoup plus fine et l alimentation d un système de supervision propre à la plate-forme pour garantir une haute disponibilité. De plus, ils permettront de mettre en place des mécanismes de réplications entre différents sites calculs. Plusieurs difficultés sont à surmonter : - une automatisation du processus d encapsulation des codes, - une performance à la hauteur des attentes des internautes et des auteurs, - Les calculs distribués sur les centres de calculs pour répondre aux sites thématiques et RO, - L ordonnancement des demandes afin de desservir aussi bien un internaute qui demande l'exécution d'un calcul rapide que celui qui demande un ensemble de calculs importants. D où la collaboration avec le Laboratoire d'informatique de Tours pour les problématiques liées à l'ordonnancement. Résultats scientifiques : Les résultats scientifiques espérés sont une accélération de la diffusion et une valorisation de la production scientifique. Une meilleure utilisation des méthodes et des programmes développés, la possibilité de répliquer les résultats de calculs et de comparer différentes approches. Permettre aux chercheurs d'avoir des feedback direct ou par reporting sur leurs différentes réalisations ; vérifier la robustesse d un algorithme, d une méthode face à de nombreuses sollicitations, permettre aux différents acteurs d échanger dans des espaces en dehors ou au sein de la plate-forme (espace collaboratif de différents types blog, forum, wiki, développement de type git ). L appui de certains éditeurs pourrait favoriser l émergence de cette solution dans la sphère académique et ainsi améliorer les processus de validation, de diffusion et de valorisation de la recherche. Permette de créer une dynamique autour de cette plate-forme entre les différents types utilisateurs (Les auteurs de site et les utilisateurs de ces sites). Permettre le partage de données, de résultats et ainsi la possibilité de constituer des banques de données (d images, de fichiers texte ). Eléments de références permettant de comparer les effets et améliorations possibles de traitements nouveaux. Mise en place d une communauté et ainsi favoriser l émergence de collaboration autour de problématique commune. Perspectives : Les perspectives de déploiement : au sein de la discipline Economie-Gestion à hauteur de 100 sites compagnons d ici fin d année 2012, ce nombre devrait avec l apport d une collaboration avec les éditeurs ELSEVIER, SSRN connaître un accroissement considérable pour les années suivantes. On compte dans cette seule discipline entre 800 et 1000 sites compagnons par an si on se base sur l ensemble des revues SHS. Le tout pouvant être encore augmenté avec l arrivée d ici 2013 de l accompagnement de conférences ou colloques qui devrait permettre de voir l émergence de ce concept dans cette sphère scientifique. Le déploiement dans les autres disciplines est prévu pour Septembre 2012 dans le champ disciplinaires des Mathématiques et dans le champ disciplinaire de la Bio-Statistiques prévu février Cette action devrait amener dans sa première année environ 200 sites compagnons supplémentaires. Les autres champs disciplinaires ont déjà été rapprochés et sont en cours de spécifications. Pour une intégration prévue Développement communautaire : des perspectives de mise en place autour de cette plate-forme d un système de collaboration devrait pouvoir accroitre l intérêt des échanges autour de ces productions numériques. Dans cette phase, le 4 70/88

73 partage à l échelle mondiale devrait amener un nouveau moyen de communication scientifique. Développement et couplage géographique : Le couplage multi-sites doit permettre de supporter cette demande croissante dans ce milieu par la mise en place de ce concept. On prévoit fin d année 2012 un couplage effectif entre le frontal de TGE-ADONIS et le centre de calculs d Orléans (CCSC). Le développement d un réseau social autour de ce concept permettant et facilitant l émergence d échange et de collaboration entre les différents acteurs est en cours d étude devrait voir le jour courant Références : Ince, Hatton and Graham-Cumming, "The Case for Open Computer Programs", Nature, February 2012, 482, Stodden V. and Arbesman S., "Scientists, Share Secrets or Lose Funding, Bloomberg View, Jan 10, 2012 Morin et al, Shining Light into Black Boxes, Science, April /88

74 Détection a posteriori de structure génétique des populations hiérarchisée Maxime Pauwels (1), Adeline Coorneart (2), Sophie Gallina (3), Cyrille Bonamy (4), Jean-François Arnaud (5) (1) maxime.pauwels@univ-lille1.fr, UMR-CNRS 8198 (2) adelinecoornaert@yahoo.fr, UMR-CNRS 8198 (3) sophie.gallina@univ-lille1.fr, UMR-CNRS 8198 (4) cyrille.bonamy@univ-lille1.fr, CRI Université Lille 1 (5) jean-francois.arnaud@univ-lille1.fr, UMR-CNRS 8198 Overview: Our study aim is to determine whether the Bayesian clustering method implemented in the STRUCTURE software is capable of detecting hierarchical population genetic structure. Using simulations under two hierarchical migration models, various sets of genotypic data were obtained, corresponding to various levels of genetic differentiation among groups of populations. Twelve datasets were analyzed with and without multiple sub-sampling of the number of genetic locus, individuals and populations. Finally, 556,800 runs of the STRUCTURE software were required for analyses. Runs were submitted to either the CRI cluster or the European grid using Perl scripts, and results were secondary analyzed on the local server. Enjeux scientifiques, besoin en calcul, stockage et visualisation : En génétique des populations, on définit la structure en population de la diversité génétique comme la distribution nonaléatoire de cette diversité dans différents ensembles d'individus appelés populations (Hartl & Clark, 2007). Par définition, ces populations représentent des ensembles entre lesquels les échanges génétiques par migration sont réduits, du fait de l existence de barrières aux flux de gènes. Identifier ces groupes au sein d espèces biologiques d intérêt est un défi majeur lorsqu il s agit par exemple de définir des unités sur lesquelles opérer dans le cadre d un programme de conservation. Plusieurs outils informatiques d'analyse bayésienne, dits "de regroupement", sont aujourd'hui disponibles pour le généticien des populations qui souhaite déterminer a posteriori le nombre et les limites de ces populations à partir de données de génotypage moléculaire d'un échantillon d'individus. Nous avons testé l'efficacité d'un de ces outils, implémenté dans le logiciel STRUCTURE (Pritchard et al., 2000) en l'utilisant pour analyser des jeux de données simulées sous deux modèles définissant une structuration hiérarchisée de la diversité génétique, c'est-à-dire lorsque un nombre déterminé de populations sont aussi regroupées en un nombre déterminé de groupes de populations génétiquement isolés. Pour chacun des deux modèles, 6 paramétrages ont abouti à l'obtention de 6 jeux de données distincts, comprenant 100 marqueurs génétiques dont la diversité est distribuée dans 30 ou 32 populations regroupées en 5 ou 2 ensembles, respectivement. Chacun des douze jeux de données a ensuite était analysé à l'aide du logiciel STRUCTURE en faisant varier le paramètre K (nombre de populations), à estimer, de 1 à 40. Pour chaque valeur de K, le logiciel a été lancé 10 fois afin d'estimer la variance statistique de la vraisemblance des paramètres correspondante (soit un total de 400 runs par jeux de données). Les analyses ont ensuite été réalisées après sous-échantillonnage aléatoire, pour chaque jeu de données, du nombre de locus (3 réductions), du nombre d'individus par population (2 réductions) et du nombre de populations par groupe (1 réduction). Chaque sous-échantillonnage a été effectué 5 fois pour estimer l'effet statistique du sous-échantillonnage. Au total, runs du logiciel du STRUCTURE ont été nécessaire pour analyser les données (complètes et réduites) de chacun des 2 modèles de simulations. Les résultats d'analyse ont ensuite été rapatriés sur serveur local de notre laboratoire, compilés, reformatés et synthétisés pour permettre différentes représentations graphiques. Développements, utilisation des infrastructures : Les simulations de données ne nécessitant pas de grandes capacités de calcul, elles ont été effectuées à l'aide du logiciel NEMO (Guillaume & Rougemont, 2006) sur un ordinateur personnel, puis transférées sur le cluster du mésocentre Lillois (CRI de Lille 1). L'analyse des 12 jeux de données complets et d'un premier sous-échantillonnage des données a été réalisée sur le cluster du mésocentre Lillois. Des scripts PERL ont été développés pour lancer les différents jobs, contrôler la qualité des analyses effectuées, organiser la sauvegarde des résultats et transférer les résultats sur le serveur local de notre laboratoire. Etant donnée l'ampleur des temps de calcul nécessaire au cours de cette première étape ( heures de calcul, soit 6943 jours ou 19 ans), l'analyse d'1 seul réplicat de sous-échantillonnage pour le nombre de locus, d'individus et de populations a été réalisée sur le cluster du mésocentre Lillois. Pour réaliser les 5 réplicats de sous-échantillonnage nécessaire à ce projet, nous avons ensuite utilisé la Grille EGI, via la VO Biomed et l'instance nationale et multi-communauté de DIRAC pour France Grilles (Arrabito et al 2012). Comme un ensemble de scripts PERL avait déjà été développé pour la solution «calcul sur cluster», nous avons choisi d'adapter ces scripts pour la solution «calcul sur grille via DIRAC». Nous n'avons donc pas utilisé l'api Dirac en python. L'adaptation a principalement consisté à générer des fichier JDL au lieu de fichiers PBS, et à utiliser la commande dirac-wms-job-submit à la place de la commande qsub. Les identifiants des jobs soumis ont été stockés dans un fichier local, qui a ensuite servi à tester le statut des jobs avec la commande dirac-wms-job-status, à rapatrier les résultats avec dirac-wms-job-get-output et enfin à détruire les jobs avec dirac-wms-job-delete. Ces 4 primitives, d'utilisation très simples, permettent de gérer les jobs par lot. Nous avons utilisé des lots de 100 jobs pour vérifier les statuts, récupérer les résultats des N jobs / 100 qui étaient terminés puis les détruire. Cette technique diminue la charge du serveur DIRAC et donc réduit les temps de réponse. Au 72/88

75 total, les 3 scripts pour 1) soumettre les jobs, 2) rapatrier les résultats et 3) détruire les jobs représentent 250 lignes de code Perl, donc un très faible investissement en temps de développement. Par ailleurs, nous avons choisi d'utiliser directement une version exécutable pour processeur 64bits du programme Structure, sans chercher à le recompiler sur les nœuds de la grille, car ce programme n'utilise que des librairies standards. Environ 2% des jobs lancés ont retourné un statut d'erreur. Outils, le cas échéant complémentarité des ressources, difficultés rencontrées : Les besoins informatiques pour notre projet concernant principalement des calculs paramétriques, le mesocentre Lillois nous semblait bien adapté. Cela nous a permis de réaliser une première étape dans ce projet en analysant un premier réplicat de ré-échantillonnage. Cependant, l'analyse complète de tous les réplicats ne pouvait pas être réalisée avec les seuls ressources du mésocentre. L'ingénieur responsable du mésocentre nous a alors orienté vers l'utilisation de l'instance nationale DIRAC et nous a fourni une aide précieuse pour les aspects administratifs de demande d'entrée dans la grille, le choix et l'installation des outils et des certificats et enfin une aide technique pour l'utilisation des ressources via des scripts PERL de base pour la soumission et la récupération des résultats. Nous avons ensuite adapté ces scripts afin de lancer les commandes par lots pour la récupération des résultats, ce qui a réduit le temps pour nous et probablement allégé la consommation de ressources sur l'instance DIRAC. Le mésocentre Lillois teste actuellement la possibilité de faire des soumissions de jobs paramétriques, nous prévoyons donc d'utiliser cette technique dès qu'elle sera validée par le mésocentre. Résultats scientifiques : Les résultats permettent de discuter la puissance de détection d'une structuration génétique de la diversité génétique par le logiciel de regroupement bayesien STRUCTURE en fonction du niveau d'isolement génétique entre les populations ou groupes de populations et de la quantité d'information disponible (nombre de locus, d'individus, de populations). A travers la comparaison des résultats obtenus à partir des différents jeux de données, nous avons pu obtenir une lecture plus instruite et donc plus critique des représentations graphiques des résultats d'analyse. Nous avons pu montrer que le logiciel était particulièrement sensible aux faibles niveaux de différentiation entre population/groupes de populations et à la quantité d'information analysées, notamment le nombre de locus. Perspectives : L'analyse effectuée, parce qu'elle nécessitait l'exploitation de capacités de calcul importantes, était inimaginable sans les ressources fournies par la grille. Par conséquent, notre protocole a initialement été défini en réduisant les modalités de tests des capacités du logiciel STRUCTURE, notamment par exemple, en limitant les paramétrages possibles du logiciel. Le significatif gain de temps associé à l'utilisation de la grille rend envisageable une complémentation des résultats obtenus par une multiplication des conditions d'analyses de jeux de données génétiques simulés. Références : Guillaume F, Rougemont J Nemo: An evolutionary and population genetics programming framework. Bioinformatics 22(20): Hartl DL, Clark AG Principles of population genetics. Sunderland, Massachusetts: Sinauer Associates, Inc. Pritchard JK et al Inference of population structure using multilocus genotype data. Genetics 155(2): Arrabito L et al Instance nationale et multi-communauté de DIRAC pour France Grilles. Journées scientifiques mésocentre et France grilles 1-3 octobre 2012 Paris 73/88

76 MetaMatch : un algorithme pour l'assignation taxonomique en métagénomique Jean-Marc Frigerio (1), Philippe Chaumeil (1), Pierre Gay (2), Lenaïg Kermarrec (3,4), Frédéric Rimet (3), Agnès Bouchez (3) et Alain Franc (1) (1) {Jean-Marc.Frigerio, Alain.Franc, Philippe.Chaumeil}@pierroton.inra.fr, INRA, UMR1202 BIOGECO, F Cestas, France & Univ. Bordeaux, BIOGECO, UMR 1202, F Talence, France (2) Pierre.Gay@u-bordeaux1.fr, Univ. Bordeaux, MCIA, F Talence, France (3) {Agnes.Bouchez, Frederic.Rimet@thonon.inra.fr}@thonon.inra.fr, INRA, UMR CARRTEL, Thonon-les-Bains et Université de Savoie, Chambéry, France (4) lenaig.kermarrec@asconit.com, Asconit Consultants, Toulouges, France Overview Community ecology faces a new challenge as the next-generation sequencing approaches can yield data from hundreds of microbial community samples. This way, combined with accurate and reliable taxonomic assessment, yields hundreds of new data that will contribute to a better understanding of community assemblies formed under various environmental and historical conditions. Algorithms classifying sequences by comparison to a reference library are the most widely used tools for assessing community composition of environmental samples. However, as they are computationally intensive, almost all these algorithms (most standard being BLAST and similar offsprings) use heuristics designed to speed up the database exploration phase, at the cost of being less strict with the quality of the match between a query and a reference. This problem is naturally distributable, as all comparisons (query, reference) are independent. Here, we present a tool enabling comparisons between queries ( say, one million reads) and reference sequences (say, several thousands), and its implementation on two infrastructures: a cluster in MCIA (Mésocentre de Calcul Intensif en Aquitaine) and a production grid EGI. We show how tracking the large number of jobs generated was nearly impossible with glite, and how this problem could be solved using Dirac. We compare time and quality between a run on Avakas and on the grid EGI. As a perspective, we will develop a user friendly interface enabling this tool to be used routinely on the grid as a diagnostic for a user not acquainted with computing subtleties of the grid. Enjeux scientifiques Les techniques de séquençage ont prodigieusement évolué ces dernières années, déversant ce qu'il est convenu d'appeler des avalanches de données. Les outils de modélisation statistique et traitement qui étaient dimensionnés pour des productions bas débit sont dépassés, et il existe une forte demande à la fois de transferts vers des machines performantes (clusters, grille) et vers le développement de nouveaux algorithmes adaptés à ces nouvelles dimensions. Ici, nous nous intéressons aux comparaisons de séquences. Actuellement, le programme d alignement local de séquences le plus largement utilisé, BLAST (Basic Local Alignment Search Tool, Altschul et al., 1990) se décline sous des dizaines de variantes développées depuis 1990, améliorant tel ou tel point de performance. La liste est trop longue pour la mentionner ici. Il effectue des comparaisons de séquences via une heuristique proche d'une distance. Ici, nous présentons metamatch, un outil dans la filiation de BLAST, avec une logique légèrement différente (sans entrer dans les détails, les ancres pour alignement sont calculées dans metamatch en début de processus, alors que dans BLAST, elles sont étendues en cours de processus). Une séquence est une chaîne de caractère dans un alphabet à quatre lettres. Il existe plusieurs façons de calculer une distance entre deux séquences, avec un temps en général proportionnel au produit des deux longueurs. L'enjeu est, connaissant un ensemble de reads (séquences de quelques centaines de bases produites par un séquenceur de nouvelle génération) et une librairie de référence (des séquences d'organismes connus taxonomiquement) de calculer la distance de chaque read à chaque séquence de référence, et de ne retenir pour assignation taxonomique que les plus proches si les informations qu'elles infèrent sont cohérentes et concordantes. Nous avons mis au point un algorithme d'alignement sur ancres (parties identiques maximales), de calcul de distance entre les ancres selon un alignement global, et, le plus délicat, de gestion (imparfaite..) des extrémités. Pour 10 6 reads de longueur et références de longueur , cela représente de l'ordre de opérations élémentaires. La distribution des calculs est alors obligatoire. Développement, utilisation des infrastructures La parallélisation ou distribution d'outils tels que BLAST ou metamatch est naturelle et, pour BLAST notamment, a été largement étudiée (Carvalho & al., 2005, Missaoui, 2009), notamment la distribution sur des plate-formes hétérogènes comme une grille de calcul (Afgan & al., 2006), avec équilibrage dynamique (dynamic-scheduler) sur grille comme pour l'alignement (Chen et Schmidt, 2005). Le portage de metamatch sur la grille EGI fait partie de ce mouvement très général et naturel de transferts d'outils en biologie vers des plate-formes distribuées de calcul (Talbi et Zomaya, 2008). Dans cette même veine, la V.O. GRISBI facilite l'accès à de nombreux outils de bioinformatique (Blanchet & al., 2006). Le développement s'est déroulé en trois phases. Une première phase a été de concevoir l'algorithme, de l'implémenter en langage C, et de le tester sur des petits jeux de données, à portée d'un ordinateur personnel type PC. Une seconde étape a été de tester son efficacité sur des jeux de données réels par distribution sur les nœuds d'un cluster. Notre choix s'est porté sur le cluster Avakas du mésocentre de calcul MCIA (3168 cœurs Intel Xeon X5675 à 3.06GHz accessibles via l'ordonnanceur TORQUE/MAUI). Cet essai a 74/88

77 servi de benchmark pour le scheduler d'avakas, lors de la phase de Vérification de Service Régulier. Cette utilisation simultanée de l'ensemble des cœurs pour une seule tâche (fortement déconseillée dans le cahier des bonnes pratiques) ne pouvant être qu'exceptionnelle, la version stabilisée de cet algorithme a été écrite pour une distribution sur un milliers de CPU environ. La troisième phase a été la mise en œuvre sur la grille EGI, via la V.O. MCIA. Une premier essai a été réalisé via l'utilisation de lignes de commandes glite. Le nombre important de jobs ainsi lancés sur plusieurs machines a rendu délicate l'opération de suivi de chacun, et ces essais n'ont pas abouti. Finalement, nous avons utilisé Dirac sur la V.O. France-Grille pour distribuer ces calculs sur la grille. DIRAC est à la fois une interface très conviviale de gestion de jobs lancés sur la grille et une API permettant cette même gestion de façon plus versatile encore, via des scripts python. La stratégie la plus efficace fut de lancer les 1200 jobs via un petit script utilisant l'api et de surveiller l'évolution des jobs au travers de l'interface Web. La récupération des résultats s'est faite naturellement via l'interface. Résultat Scientifique Afin de tester notre algorithme metamatch, nous l'avons mis en œuvre en concurrence avec BLAST pour étudier un problème de bioindication de la qualité des eaux après inventaire de communautés de diatomées (Kermarrec, 2012, Kermarrec & al., 2012). Les communautés de diatomées sont un bioindicateur reconnu de la qualité des eaux : il existe un indice construit à partir d'un inventaire taxonomique qui permet de classer les rivières ou lacs selon la qualité de leurs eaux. Plusieurs échantillons ont été pyroséquencés (technologie Roche 454) pour une région d'intérêt taxonomique (SSU rdna, Medlin et al., 1988). Trois échantillons ont été construits artificiellement en associant des cultures de diatomées, afin de vérifier si notre algorithme permettait de retrouver cet assemblage connu, et quatre échantillons naturels ont été prélevés dans différents écosystèmes. Le résultat présenté ici concerne les échantillons artificiels. Les temps de calcul de BLAST et metamatch sont du même ordre de grandeur, mais fiabilité et précision sont supérieures pour metamatch, qui fournit moins de faux positifs que BLAST. Sur 21 espèces dont les cultures ont été assemblées, BLAST et metamatch en ont retrouvé 20, metamatch a ajouté un faux positif, assez proche d'une espèce présente, alors que BLAST dans ses différentes implémentations a ajouté environ dix faux positifs, dont plusieurs éloignés taxonomiquement de l'échantillon connu. La qualité de l'inventaire avec metamatch et deux choix pour BLAST (taille des ancres) est indiquée dans la figure 1. Chaque procédure pour chaque échantillon produit un inventaire (il y a eu trois procédures différentes de construction de l'assemblage avec les mêmes espèces), et metamatch fournit des inventaires plus proches du réel (KNOWN) que BLAST ou UBLAST. Figure 1: Dendrogramme de classification ascendante hiérarchique sur distances de Jaccard entre 16 inventaires d un même assemblage d espèces de diatomées. KNOWN est l inventaire connu (espèces utilisées pour créer l échantillon artificiel); Mx_metaMatch sont les inventaires obtenus avec metamatch; Mx_BLAST_.. sont les inventaires obtenus avec BLAST; Mx_UBLAST_.. sont les inventaires obtenus avec UBLAST. Les inventaires réalisés avec metamatch sont systématiquement plus proche de l'inventaire connu (LK & al., submittted). 75/88

78 Perspectives La taxonomie moléculaire, bien qu'ancienne (Hillis & al., 1996) est en plein développement et à la base des études de biodiversité (Hébert & al., 2003) : il faut connaître la diversité des communautés pour analyser leur fonctionnement ou les services qu'elles peuvent rendre (production, conservation, épuration, molécules chimiques, etc ) ou comme bioindicateur de qualité des écosystèmes (comme la diversité des diatomées pour la qualité des eaux). Il existe plusieurs dizaines de millions d'espèces différentes, dont la majorité ne sont pas connues ni décrites. La taxonomie s'oriente vers la taxonomie moléculaire, et les séquenceurs de nouvelle génération permettent un accès à des données sur l'ensemble des organismes d'une communauté (métagénomique), ce qui était impossible auparavant. La comparaison avec des séquences de référence sur organismes connus est une étape essentielle pour asseoir sur des bases solides la taxonomie moléculaire. La plupart des algorithmes et méthodes, comme celle présentée ici, reviennent en fait à comparer des séquences inconnues (les reads), avec des informations bien connues dans une base de référence. Ces opération se prêtent naturellement à la distribution, et cette stratégie de portage sur la grille avec un souci d'accès simplifié via un portail comme Dirac a pour perspective de se diversifier fortement. On peut ainsi penser au phylotypage qui, plus que donner une distance entre séquences, permet d'insérer en un temps linéaire un read de nature inconnue sur une phylogénie connue de la base réalisée une fois pour toute (Matsen & al., 2010), et de progresser ainsi vers une utilisation fluide d'une variété d'outils en taxonomie moléculaire sur la grille de calcul EGI. Références Afgan, E., Sathyanarayana, P. et Bangalore, P Dynamic Task Distribution in the Grid for BLAST. IEEE International Conference on Granular Computing Altschul, S.F., Gish, W., Miller, W., Myers, E.W. and Lipmanl, D.J Basic Local Alignment Search Tool, J ournal of Molecular Biology, 215: Blanchet, C., & al Grid deployment of legacy bioinformatics applications with transparent data access, in 7th IEEE/ACM International Conference on Grid Computing (GRID 2006), September 28-29, 2006, Barcelona, Spain, Proceedings. Carvalho, P. C., Glória, R.V., de Miranda, A. B. et Degrave, W. M Squid a simple bioinformatics grid. BMC Bioinformatics, 6:197 - doi: / Chen, C. et Schmidt, B An adaptive grid implementation of DNA sequence alignment, Future Generation Computer Systems, 21: Jaziri & al Détermination de sondes oligonucléotidiques pour biopuces phylogénétiques en environnement grille de calcul. Communication aux Journées Scientifiques de France-Grille, Lyon, Hebert P. D. N., Cywinska A., Ball S. L., et dewaard J. R Biological identifications through DNA barcodes. Proc. Natl. Acad. Sci. U.S.A. 270: Hillis D. M., Moritz C., et Mable B Molecular Systematics. 2 e édition. Sunderland, Massachusetts: Sinauer Associates. Kermarrec, L Apport des outils de la biologie moléculaire pour l'utilisation des diatomées comme bioindicateurs de la qualité des écosystèmes aquatiques lotiques, et pour l'étude de leur taxonomie. Thèse de l'université de Grenoble. Kermarrec, L., Chaumeil, Ph., Rimet, F., Frigerio, J.-M., Bouchez, A. & Franc, A. - xxxx metamatch, a tool for metabarcoding. Soumis. Matsen, F. A., Kodner, R. B. et Armbrust, E. V pplacer : linear time maximum likelihood and Bayesian phylogenetic placement of sequences onto a fixed reference tree. BMC Bioinformatics, 11:538, doi: / Medlin, L. K., Elwood, H. J., Stickel, S. & Sogin, M.L The characterization of enzimatically amplified eukaryotic 16S-like rrna-coding regions. Gene, 71: Missaoui, M Contributions algorithmiques à la conception de sondes pour biopuces à ADN en environnement parallèle. Thèse, Université Blaise Pascal, Talbi, E.-G. Et Zomaya, A.Y. (Ed.) Grid Computing for Bioinformatics and Computational Biology. Wiley. 76/88

79 Accélération du traitement de données avioniques : Hadoop@PireCloud François Thiebolt(1), Aurélien Ortiz(2), Congduc Pham(3), Jean-Marc Pierson(4) (1) thiebolt@irit.fr, IRIT UMR 5505 (2) aortiz@serviware.com, ServiWare Toulouse (3) congduc.pham@univ-pau.fr, Université de Pau et des pays de l'adour (4) pierson@irit.fr, IRIT UMR 5505 Overview : During a flight, every aircraft monitors and collects numerous data like speed, altitude, oil pressure, temperature, acceleration and so on. A small aircraft (up to 10 seats) generates something like 2GB of data every year which is very small comparing to a company managing more than 200 Airbus A320. Every time a plane has landed, the in-flight data are collected for an off-board analysis to determine whether the aircraft requires any maintenance session. Efficiency and accuracy of this analysis is very important to keep the aircrafts flying at their maximum. 2Moro is a french company specialized in the analysis of such data. To face the ever increasing amount of in-flight data and to improve the responsiveness of their tools, we proposed them to switch from a monolithic approach to a cloud solution featuring the Hadoop framework [HAD]. This work was part of the Aragon-Aquitaine project named «OMNI-DATA» [CPH] Les besoins : Produire de la valeur ajoutée à partir du traitement de données de vol passe par un cycle d'analyse et de comparaison avec des états antérieurs. Le tableau de bord associé à chaque appareil donne ainsi à l'utilisateur une vision claire de l'état de sa flotte et lui permet d optimiser la planification des sessions de maintenance. Fig. I : Approche monolithique du cycle de traitement des données de vol. Dans ce workflow (fig. I), les données de vol collectées sont converties sous une forme exploitable pour être ensuite ajoutées à la base contenant l'ensemble des paramètres de vols. Le cycle d'analyse qui s'exécute sur un seul nœud de calcul extrait les informations et enregistre les résultats dans cette même base. Avec un nombre croissant d'appareils et des volumes de données générées par chacun d'eux en constante augmentation, la nécessité d'une approche parallèle du traitement des informations de vol s'impose. Fig. II : Nouvelle approche MapReduce du traitement des données de vol. La répartition des données dans le système de fichiers HDFS et l'exploitation parallèle de plusieurs nœuds de calcul (fig. II) va permettre d'augmenter considérablement la réactivité du cycle d'analyse et de ce fait de produire plus rapidement de la valeur ajoutée pour l'utilisateur final. Maintenant, l'exploitation du parallélisme dans le traitement des données de vol passe par la mise en œuvre du paradigme MapReduce ce qui signifie la ré-écriture du cœur de l'outil d'analyse. PireCloud : Sur la période allant de 2009 à 2012, le programme européen Interreg IV A du POCTEFA a cofinancé la mise en œuvre d'une grille de calcul entre l'espagne et la France. L'objectif était d'aider et d'accompagner les entreprises à s'approprier des technologies de traitement de données déjà couramment utilisées dans le monde de la recherche. PireGrid[Pir02] a été cette plateforme de calcul opérationnelle sur 4 sites dans les régions d'aragon, de Navarre, d'aquitaine et de Midi-Pyrénées. 77/88

80 Par la suite, pour compléter l'offre aux entreprises, PireGrid est devenu PireCloud avec la mise à disposition d'une plateforme de Cloud notamment sur le site de Pau. Pour ce faire, nous avons mis en place l'outil de management de machines virtuelles «Open Nebula» [OpN] ainsi qu'un accès par VPN. Pour gagner en accessibilité, nous avons rendu visible depuis Internet les machines virtuelles déployées au sein du cluster. Enfin, pour conserver les fonctionnalités de la grille, les services Glite [GLI] (v3.2) ont été virtualisés ce qui permet à la plateforme de Pau de fonctionner simultanément dans les deux modes. C'est donc dans ce contexte PireCloud qu'ont été menées les expérimentations avec la société 2Moro (fig. III). Fig III : Déploiement des outils 2Moro sur PireCloud avec Haddop Pour valider la pertinence de l'analyse de données de vol sur une plateforme de type Cloud, la société 2Moro a fait appel à l'outil de modélisation de workflow Intalio [INT]. Fig IV : Vue d'ensemble du workflow d'analyse de données de vol Fig V : Génération d'alertes relatives à la phase d'atterrissage. 78/88

81 Le workflow global (fig. IV) fait apparaître des traitements spécifiques liés aux différentes phases de vol. L'analyse simplifiée de la phase d atterrissage (fig. V) va ainsi générer des alertes en fonction de la vitesse et de l'altitude. Résultats : Le site PireCloud de Pau dispose de 16 lames ce qui représente un total de 128 processeurs Xeon Ghz et 768Go de RAM. L'environnement de test fait appel à 4 machines virtuelles Ubuntu (2 cpu, 4Go ram parm VM) déployées via OpenNebula v3.0. La configuration Hadoop sur ces VMs fait état d'un nœud maître et de 3 nœuds esclaves. Fig VI : Jeu de données de vol. Les données d'entrée (fig. VI) fournies par 2Moro ont été réparties sous la forme de 4 fichiers de 64Mo dans le système de fichiers HDFS. Le code 36 représente la vitesse. Fig. VII : Extrait des résultats relatifs à l'analyse de la phase d atterrissage. La figure VII présente un extrait des résultats d'analyses relatifs à la phase d atterrissage, les autres résultats n'ont pas été présentés pour la clarté du document. Dans cette configuration de test, le traitement des données de vol s'est ainsi déroulé globalement trois fois plus vite qu'avec l'ancienne approche basée sur une solution faisant appel à un seul serveur accédant à une base de données centralisée. L'objectif de la démonstration sur une plateforme de type Cloud a ainsi été atteint. Perspectives : Ces résultats préliminaires ont pour l'essentiel permis à la société 2Moro de mettre en évidence la pertinence d'une approche basée sur le traitement de données de vol via le paradigme MapReduce dans une infrastructure de type Cloud, ce 79/88

e-biogenouest CNRS UMR 6074 IRISA-INRIA / Plateforme de Bioinformatique GenOuest yvan.le_bras@irisa.fr Programme fédérateur Biogenouest co-financé

e-biogenouest CNRS UMR 6074 IRISA-INRIA / Plateforme de Bioinformatique GenOuest yvan.le_bras@irisa.fr Programme fédérateur Biogenouest co-financé e-biogenouest Coordinateur : Olivier Collin Animateur : Yvan Le Bras CNRS UMR 6074 IRISA-INRIA / Plateforme de Bioinformatique GenOuest yvan.le_bras@irisa.fr Programme fédérateur Biogenouest co-financé

Plus en détail

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec.

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec. 3A-IIC - Parallélisme & Grid Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Principes et Objectifs Evolution Leçons du passé Composition d une Grille Exemple d utilisation

Plus en détail

Mise en place d'un gestionnaire de données léger, pluridisciplinaire et national pour les données scientifiques

Mise en place d'un gestionnaire de données léger, pluridisciplinaire et national pour les données scientifiques Mise en place d'un gestionnaire de données léger, pluridisciplinaire et national pour les données scientifiques Catherine Biscarat pour le groupe irods de France Grilles D. Benaben,, Y. Cardenas, P. Gay,

Plus en détail

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department DB GT CF Grid ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Group Information Department Journée de la communauté FUSE, Paris, 2010 CERN IT Department CH-1211 Geneva 23 Switzerland

Plus en détail

Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud. Grid and Cloud Computing

Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud. Grid and Cloud Computing Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud Grid and Cloud Computing Problématique Besoins de calcul croissants Simulations d'expériences coûteuses ou dangereuses Résolution de

Plus en détail

Charte d'utilisation des infrastructures de la plate-forme bioinformatique Genotoul

Charte d'utilisation des infrastructures de la plate-forme bioinformatique Genotoul Page 1/5 Objet de la modification Tableau des modifications Création du document 06/2014 Interdiction de lancer tout traitement de données sur les serveurs frontaux et purge du work sans préavis si fichiers

Plus en détail

UTILISATION DE LA PLATEFORME WEB D ANALYSE DE DONNÉES GALAXY

UTILISATION DE LA PLATEFORME WEB D ANALYSE DE DONNÉES GALAXY UTILISATION DE LA PLATEFORME WEB D ANALYSE DE DONNÉES GALAXY Yvan Le Bras yvan.le_bras@irisa.fr Cyril Monjeaud, Mathieu Bahin, Claudia Hériveau, Olivier Quenez, Olivier Sallou, Aurélien Roult, Olivier

Plus en détail

DIRAC : cadre et composants pour créer des systèmes de calcul distribués

DIRAC : cadre et composants pour créer des systèmes de calcul distribués Licence Creative Commons by-nc-nd (Paternité, pas d'utilisation commerciale, pas de modification) Logiciel validé par la communauté Ens Sup - Recherche DIRAC : cadre et composants pour créer des systèmes

Plus en détail

Services à la recherche: Data Management et HPC *

Services à la recherche: Data Management et HPC * Services à la recherche: Data Management et HPC * Pierre-Yves Burgi et Jean-François Rossignol Division informatique (DINF) * HPC = High-Performance Computing Réunion CIF Sciences du 6.12.11 1/19 Contenu

Plus en détail

Middleware et services de la grille

Middleware et services de la grille 1 2 La vision EGEE (Enabling Grids for E-sciencE) Création d une infrastructure Grid à travers l Europe, qui implique les réseaux de recherches scientifiques actuelle et futur Offrir à la communauté des

Plus en détail

Forthcoming Database

Forthcoming Database DISS.ETH NO. 15802 Forthcoming Database A Framework Approach for Data Visualization Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH for the degree of Doctor of

Plus en détail

Un exemple de cloud au LUPM : Stratuslab

Un exemple de cloud au LUPM : Stratuslab Un exemple de cloud au LUPM : Stratuslab Plan de la présentation Le cloud : une idée nouvelle? La boîte à outils du cloud Les différents types de cloud (Iaas, Paas, Saas) Présentation de Stratuslab Démonstration

Plus en détail

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services 69 Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services M. Bakhouya, J. Gaber et A. Koukam Laboratoire Systèmes et Transports SeT Université de Technologie de Belfort-Montbéliard

Plus en détail

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 MapReduce Malo Jaffré, Pablo Rauzy ENS 16 avril 2010 Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 Qu est ce que c est? Conceptuellement Données MapReduce est un framework de calcul distribué

Plus en détail

FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE. Database as a Service (DBaaS)

FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE. Database as a Service (DBaaS) FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE Database as a Service (DBaaS) 1 The following is intended to outline our general product direction. It is intended for information purposes only, and may

Plus en détail

Eco-système calcul et données

Eco-système calcul et données Eco-système calcul et données M. Daydé Dr du Comité d'orientation pour le Calcul Intensif (COCIN) Délégué Scientifique INS2I en charge HPC / Grille / Cloud Calcul / données : un enjeu stratégique Calcul

Plus en détail

Iyad Alshabani SysCom - CReSTIC Université de Reims 17/02/2011 1

Iyad Alshabani SysCom - CReSTIC Université de Reims 17/02/2011 1 SysCom - CReSTIC Université de Reims 17/02/2011 1 Motivation Gestion des expérimentations Avec les workflows Simulation Simulation des Systèmes Distribués ANR USS SimGrid Campagne de Test et gestion de

Plus en détail

Architecture de la grille

Architecture de la grille 1 2 Diversité des applications et des utilisateurs (profile, nombre,...) supposent des solutions différentes architectures différentes avec des services communs Services de base authentification: établir

Plus en détail

Retour d expérience en Astrophysique : utilisation du Cloud IaaS pour le traitement de données des missions spatiales

Retour d expérience en Astrophysique : utilisation du Cloud IaaS pour le traitement de données des missions spatiales Retour d expérience en Astrophysique : utilisation du Cloud IaaS pour le traitement de données des missions spatiales Cécile Cavet cecile.cavet at apc.univ-paris7.fr Centre François Arago (FACe), Laboratoire

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

Présentation de la Grille EGEE

Présentation de la Grille EGEE Présentation de la Grille EGEE Introduction aux grilles La grille EGEE Exemples d applications en physique des particules et en sciences de la vie Le cercle vertueux Conclusion Guy Wormser Directeur de

Plus en détail

Informatique. epims : un LIMS pour la gestion des données de spectrométrie de masse TECHNOLOGIE APPLIQUÉE

Informatique. epims : un LIMS pour la gestion des données de spectrométrie de masse TECHNOLOGIE APPLIQUÉE Véronique DUPIERRIS 1, Damien BARTHE 2, Christophe BRULEY 2 epims : un LIMS pour la gestion des données de spectrométrie de masse Informatique RÉSUMÉ La protéomique constitue aujourd hui un outil de choix

Plus en détail

Vers une fédération de Cloud Académique dans France Grilles J. Pansanel pour le groupe FG-Cloud (M. Airaj, C. Cavet, V. Hamar, M. Jouvin, C.

Vers une fédération de Cloud Académique dans France Grilles J. Pansanel pour le groupe FG-Cloud (M. Airaj, C. Cavet, V. Hamar, M. Jouvin, C. Vers une fédération de Cloud Académique dans France Grilles J. Pansanel pour le groupe FG-Cloud (M. Airaj, C. Cavet, V. Hamar, M. Jouvin, C. Loomis, A. Lopez Garcia, G. Mathieu, V. Mendez, J. Pansanel,

Plus en détail

TRANSFORM IT + BUSINESS + YOURSELF

TRANSFORM IT + BUSINESS + YOURSELF TRANSFORM IT + BUSINESS + YOURSELF Copyright 2012 EMC Corporation. All rights reserved. 2 Vos environnements SAP sont complexes et couteux : pensez «replatforming» TRANSFORM IT+ BUSINESS + YOURSELF Alexandre

Plus en détail

Colloque Calcul IN2P3

Colloque Calcul IN2P3 Colloque Calcul IN2P3 Morceaux choisis 1 La mission Évolution des technologies Grille Cloud Calcul parallèle, HPC, GPU Big Data Open Access et pérennisation des données S'inscrire dans le contexte français

Plus en détail

ORACLE TUNING PACK 11G

ORACLE TUNING PACK 11G ORACLE TUNING PACK 11G PRINCIPALES CARACTÉRISTIQUES : Conseiller d'optimisation SQL (SQL Tuning Advisor) Mode automatique du conseiller d'optimisation SQL Profils SQL Conseiller d'accès SQL (SQL Access

Plus en détail

Evolution des technologies et émergence du cloud computing Drissa HOUATRA, Orange Labs Issy

Evolution des technologies et émergence du cloud computing Drissa HOUATRA, Orange Labs Issy Evolution des technologies et émergence du cloud computing Drissa HOUATRA, Orange Labs Issy Séminaire Aristote, 17 Déc. 2009 Ecole Polytechnique Palaiseau Plan L'univers du cloud Ressources Grilles, middleware

Plus en détail

PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION

PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION KEOPS Automation Espace Performance 2B, rue du Professeur Jean Rouxel BP 30747 44481 CARQUEFOU Cedex Tel. +33 (0)2 28 232 555 -

Plus en détail

La sécurité dans les grilles

La sécurité dans les grilles La sécurité dans les grilles Yves Denneulin Laboratoire ID/IMAG Plan Introduction les dangers dont il faut se protéger Les propriétés à assurer Les bases de la sécurité Protocoles cryptographiques Utilisation

Plus en détail

Infrastructure de calcul du CRRI

Infrastructure de calcul du CRRI Infrastructure de calcul du CRRI Types d'infrastructures de calcul Calcul Intensif (High Performance Computing) Tâches fortement couplées (codes vectoriels / parallèles) Supercalculateurs, SMP, clusters,

Plus en détail

APX et VCE, Modèle d industrialisation de l intégration et du déploiement. Olivier BERNARD, VCE

APX et VCE, Modèle d industrialisation de l intégration et du déploiement. Olivier BERNARD, VCE APX et VCE, Modèle d industrialisation de l intégration et du déploiement Olivier BERNARD, VCE Généralisation des réseaux, suprématie d IP Consumérisation des terminaux informatiques Evolution vers une

Plus en détail

Programmation parallèle et distribuée (Master 1 Info 2015-2016)

Programmation parallèle et distribuée (Master 1 Info 2015-2016) Programmation parallèle et distribuée (Master 1 Info 2015-2016) Hadoop MapReduce et HDFS Note bibliographique : ce cours est largement inspiré par le cours de Benjamin Renaut (Tokidev SAS) Introduction

Plus en détail

SysFera. Benjamin Depardon

SysFera. Benjamin Depardon SysFera Passage d applications en SaaS Benjamin Depardon CTO@SysFera SysFera Technologie 2001 Création 2010 Spin Off INRIA Direction par un consortium d investisseurs 12 personnes 75% en R&D Implantation

Plus en détail

Les mésocentres HPC àportée de clic des utilisateurs industriels

Les mésocentres HPC àportée de clic des utilisateurs industriels Les mésocentres HPC àportée de clic des utilisateurs industriels Université de Reims Champagne-Ardenne (URCA) Centre de Calcul ROMEO Multidisciplinary university more than 22 000 students a wide initial

Plus en détail

Principe de symétrisation pour la construction d un test adaptatif

Principe de symétrisation pour la construction d un test adaptatif Principe de symétrisation pour la construction d un test adaptatif Cécile Durot 1 & Yves Rozenholc 2 1 UFR SEGMI, Université Paris Ouest Nanterre La Défense, France, cecile.durot@gmail.com 2 Université

Plus en détail

Quatre axes au service de la performance et des mutations Four lines serve the performance and changes

Quatre axes au service de la performance et des mutations Four lines serve the performance and changes Le Centre d Innovation des Technologies sans Contact-EuraRFID (CITC EuraRFID) est un acteur clé en matière de l Internet des Objets et de l Intelligence Ambiante. C est un centre de ressources, d expérimentations

Plus en détail

Tableau Online Sécurité dans le cloud

Tableau Online Sécurité dans le cloud Tableau Online Sécurité dans le cloud Auteur : Ellie Fields Ellie Fields, directrice principale du marketing produits, Tableau Software Juin 2013 p.2 Tableau est conscient que les données font partie des

Plus en détail

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par.

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par. École Doctorale d Informatique, Télécommunications et Électronique de Paris THÈSE présentée à TÉLÉCOM PARISTECH pour obtenir le grade de DOCTEUR de TÉLÉCOM PARISTECH Mention Informatique et Réseaux par

Plus en détail

IBM Tivoli Monitoring, version 6.1

IBM Tivoli Monitoring, version 6.1 Superviser et administrer à partir d une unique console l ensemble de vos ressources, plates-formes et applications. IBM Tivoli Monitoring, version 6.1 Points forts! Surveillez de façon proactive les éléments

Plus en détail

Cloud et Informatique Scientifique

Cloud et Informatique Scientifique 1 Cloud et Informatique Scientifique Gilles MATHIEU gilles.mathieu@inserm.fr DSI - Coordination de l Informatique Scientifique de l Inserm (CISI) Cumulo NumBio 2015 - Juin 2015 Objectifs de cette présentation

Plus en détail

XtremWeb-HEP 8.0.0. Interconnecting jobs over DG. Virtualization over DG. Oleg Lodygensky Laboratoire de l Accélérateur Linéaire

XtremWeb-HEP 8.0.0. Interconnecting jobs over DG. Virtualization over DG. Oleg Lodygensky Laboratoire de l Accélérateur Linéaire XtremWeb-HEP 8.0.0 Interconnecting jobs over DG Virtualization over DG Oleg Lodygensky Objectives 1.Deploy Virtual Machines in XtremWeb-HEP desktop grid to: protect volunteer resources generalize «pilot

Plus en détail

EXALOGIC ELASTIC CLOUD MANAGEMENT

EXALOGIC ELASTIC CLOUD MANAGEMENT EXALOGIC ELASTIC CLOUD MANAGEMENT Jean-Marc Digne Ingénieur Avant Vente Oracle France 1 The following is intended to outline our general product direction. It is intended for information purposes only,

Plus en détail

parée e avec C. Germain, B. Kegl et M. Jouvin CS de l Université Paris Sud

parée e avec C. Germain, B. Kegl et M. Jouvin CS de l Université Paris Sud Présentation prépar parée e avec C. Germain, B. Kegl et M. Jouvin CS de l Université Paris Sud (pré)histoire de la Grille Paris Sudn1 Les besoins de la communauté HEP La collaboration physiciens/informaticiens

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Projet : Réalisation d une base de. données. Sujet : Gestion des ressources humaines. Logiciel : Microsoft Access

Projet : Réalisation d une base de. données. Sujet : Gestion des ressources humaines. Logiciel : Microsoft Access Projet : Réalisation d une base de données Sujet : Gestion des ressources humaines Logiciel : Microsoft Access Encadré par : M. Mohamed Saïd ZERRADSAHLI Réalisé par : Ben Abdelmoumen Ibtissam Challaoui

Plus en détail

Services de la grille

Services de la grille Services de la grille Abderrahman El Kharrim Division TIC CNRST, Rabat elkharrim@cnrst.ma Formation administrateurs de la grille de calcul CNRST, 27/02-02/03, 2012 1 Architecture et Middleware de la Grille

Plus en détail

Les technologies du Big Data

Les technologies du Big Data Les technologies du Big Data PRÉSENTÉ AU 40 E CONGRÈS DE L ASSOCIATION DES ÉCONOMISTES QUÉBÉCOIS PAR TOM LANDRY, CONSEILLER SENIOR LE 20 MAI 2015 WWW.CRIM.CA TECHNOLOGIES: DES DONNÉES JUSQU'À L UTILISATEUR

Plus en détail

Introduction aux bases de données: application en biologie

Introduction aux bases de données: application en biologie Introduction aux bases de données: application en biologie D. Puthier 1 1 ERM206/Technologies Avancées pour le Génome et la Clinique, http://tagc.univ-mrs.fr/staff/puthier, puthier@tagc.univ-mrs.fr ESIL,

Plus en détail

E-BIOGENOUEST, VERS UN ENVIRONNEMENT VIRTUEL DE RECHERCHE (VRE) ORIENTÉ SCIENCES DE LA VIE? Intervenant(s) : Yvan Le Bras, Olivier Collin

E-BIOGENOUEST, VERS UN ENVIRONNEMENT VIRTUEL DE RECHERCHE (VRE) ORIENTÉ SCIENCES DE LA VIE? Intervenant(s) : Yvan Le Bras, Olivier Collin E-BIOGENOUEST, VERS UN ENVIRONNEMENT VIRTUEL DE RECHERCHE (VRE) ORIENTÉ SCIENCES DE LA VIE? Intervenant(s) : Yvan Le Bras, Olivier Collin E-BIOGENOUEST Programme fédérateur Biogenouest co-financé par les

Plus en détail

Livre blanc. La sécurité de nouvelle génération pour les datacenters virtualisés

Livre blanc. La sécurité de nouvelle génération pour les datacenters virtualisés Livre blanc La sécurité de nouvelle génération pour les datacenters virtualisés Introduction Ces dernières années, la virtualisation est devenue progressivement un élément stratégique clé pour le secteur

Plus en détail

Serveur Appliance IPAM et Services Réseaux

Serveur Appliance IPAM et Services Réseaux Page 1 Datasheet Serveur Appliance IPAM et Services Réseaux SIMPLIFER LE DEPLOIEMENT DE VOS ARCHITECTURES & DHCP Les services d adressage et de nommage sont au cœur de votre système d information, car

Plus en détail

«clustering» et «load balancing» avec Zope et ZEO

«clustering» et «load balancing» avec Zope et ZEO IN53 Printemps 2003 «clustering» et «load balancing» avec Zope et ZEO Professeur : M. Mignot Etudiants : Boureliou Sylvain et Meyer Pierre Sommaire Introduction...3 1. Présentation générale de ZEO...4

Plus en détail

Chapitre 10. Architectures des systèmes de gestion de bases de données

Chapitre 10. Architectures des systèmes de gestion de bases de données Chapitre 10 Architectures des systèmes de gestion de bases de données Introduction Les technologies des dernières années ont amené la notion d environnement distribué (dispersions des données). Pour reliér

Plus en détail

Présentation par François Keller Fondateur et président de l Institut suisse de brainworking et M. Enga Luye, CEO Belair Biotech

Présentation par François Keller Fondateur et président de l Institut suisse de brainworking et M. Enga Luye, CEO Belair Biotech Présentation par François Keller Fondateur et président de l Institut suisse de brainworking et M. Enga Luye, CEO Belair Biotech Le dispositif L Institut suisse de brainworking (ISB) est une association

Plus en détail

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle 1 Principes 2 Architecture 3 4 Aperçu d utilisation

Plus en détail

HAUTE DISPONIBILITÉ DE MACHINE VIRTUELLE AVEC HYPER-V 2012 R2 PARTIE CONFIGURATION OPENVPN SUR PFSENSE

HAUTE DISPONIBILITÉ DE MACHINE VIRTUELLE AVEC HYPER-V 2012 R2 PARTIE CONFIGURATION OPENVPN SUR PFSENSE HAUTE DISPONIBILITÉ DE MACHINE VIRTUELLE AVEC HYPER-V 2012 R2 PARTIE CONFIGURATION OPENVPN SUR PFSENSE Projet de semestre ITI soir 4ème année Résumé configuration OpenVpn sur pfsense 2.1 Etudiant :Tarek

Plus en détail

Pilot4IT Tableaux de Bord Agréger et consolider l ensemble de vos indicateurs dans un même portail.

Pilot4IT Tableaux de Bord Agréger et consolider l ensemble de vos indicateurs dans un même portail. Pilot4IT Tableaux de Bord Agréger et consolider l ensemble de vos indicateurs dans un même portail. Comment exploiter au mieux l ensemble de vos indicateurs? Avec la solution agile Pilot4IT Tableau de

Plus en détail

Calcul intensif pour la biologie

Calcul intensif pour la biologie Calcul intensif pour la biologie PPF Bio-informatique et PPF Calcul intensif 14 juin 2011 Calcul intensif... Cluster : ensemble de machines homogènes et localisées, organisées en grappe Grille : infrastructure

Plus en détail

Sécuristation du Cloud

Sécuristation du Cloud Schémas de recherche sur données chiffrées avancés Laboratoire de Cryptologie Thales Communications & Security 9 Avril 215 9/4/215 1 / 75 Contexte Introduction Contexte Objectif Applications Aujourd hui

Plus en détail

Vérifier la qualité de vos applications logicielle de manière continue

Vérifier la qualité de vos applications logicielle de manière continue IBM Software Group Vérifier la qualité de vos applications logicielle de manière continue Arnaud Bouzy Kamel Moulaoui 2004 IBM Corporation Agenda Analyse de code Test Fonctionnel Test de Performance Questions

Plus en détail

Assemblée générale Aristote

Assemblée générale Aristote Assemblée générale Aristote Panorama 2011-2012 Philippe d Anfray Philippe.d-Anfray@cea.fr CEA DSM-Saclay CNES 5 juillet 2012 Assemblée générale Aristote CNES 5 juillet 2012 1 / 21 Comité de programme (1)

Plus en détail

PRODIGE V3. Manuel utilisateurs. Consultation des métadonnées

PRODIGE V3. Manuel utilisateurs. Consultation des métadonnées PRODIGE V3 Manuel utilisateurs Consultation des métadonnées Pour plus d'information sur le dispositif : à remplir par chaque site éventuellement 2 PRODIGE V3 : Consultation des métadonnées SOMMAIRE 1.

Plus en détail

Business Intelligence avec SQL Server 2012

Business Intelligence avec SQL Server 2012 Editions ENI Business Intelligence avec SQL Server 2012 Maîtrisez les concepts et réalisez un système décisionnel Collection Solutions Informatiques Extrait Alimenter l'entrepôt de données avec SSIS Business

Plus en détail

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Machine virtuelle Machine virtuelle Machine virtuelle VMware ESX Network Shutdown Module

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Tutoriel Cloud IFB - Initiation -

Tutoriel Cloud IFB - Initiation - Tutoriel Cloud IFB - Initiation - Christophe BLANCHET Institut Français de Bioinformatique - IFB French Institute of Bioinformatics - ELIXIR-FR CNRS UMS3601 - Gif-sur-Yvette - FRANCE Ecole Cumulo NumBio

Plus en détail

Jean-François Boulicaut & Mohand-Saïd Hacid

Jean-François Boulicaut & Mohand-Saïd Hacid e siècle! Jean-François Boulicaut & Mohand-Saïd Hacid http://liris.cnrs.fr/~jboulica http://liris.cnrs.fr/mohand-said.hacid Laboratoire d'informatique en Image et Systèmes d'information LIRIS UMR 5205

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBILITE CONTINUE ET MOBILITE DES DONNEES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

Sauvegarde et Restauration d un environnement SAS

Sauvegarde et Restauration d un environnement SAS Sauvegarde et Restauration d un environnement SAS 1 INTRODUCTION 3 1.1 OBJECTIFS 3 1.2 PERIMETRE 3 2 LA SAUVEGARDE 4 2.1 QUELQUES REGLES D ORGANISATION 4 2.2 DEFINIR LES BESOINS 5 2.3 LA SAUVEGARDE, ETAPE

Plus en détail

CRM PERFORMANCE CONTACT

CRM PERFORMANCE CONTACT CRM PERFORMANCE CONTACT PREMIUM 3ème génération Un concentré de haute technologie pour augmenter de 30 % vos rendez-vous Le Vinci, 2 place Alexandre Farnèse 84000 Avignon Tél : + 33 (0)4 90 13 15 88 Télécopie

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBLITÉ CONTINUE ET MOBILITÉ DES DONNÉES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

OWASP Open Web Application Security Project. Jean-Marc Robert Génie logiciel et des TI

OWASP Open Web Application Security Project. Jean-Marc Robert Génie logiciel et des TI OWASP Open Web Application Security Project Jean-Marc Robert Génie logiciel et des TI A1: Injection Une faille d'injection, telle l'injection SQL, OS et LDAP, se produit quand une donnée non fiable est

Plus en détail

White Paper - Livre Blanc

White Paper - Livre Blanc White Paper - Livre Blanc Développement d applications de supervision des systèmes d information Avec LoriotPro Vous disposez d un environnement informatique hétérogène et vous souhaitez à partir d une

Plus en détail

PLATE- FORME MUTUALISEE DE SERVICES DIFFERENCIES POUR USAGES D ETABLISSEMENTS D ENSEIGNEMENT SUPERIEUR ET DE RECHERCHE ET APPLICATIONS METIER

PLATE- FORME MUTUALISEE DE SERVICES DIFFERENCIES POUR USAGES D ETABLISSEMENTS D ENSEIGNEMENT SUPERIEUR ET DE RECHERCHE ET APPLICATIONS METIER Fonds National pour la Société Numérique Programme d Investissements d Avenir «AAP Cloud Computing» UnivCloud PLATE- FORME MUTUALISEE DE SERVICES DIFFERENCIES POUR USAGES D ETABLISSEMENTS D ENSEIGNEMENT

Plus en détail

Novembre 2013. Regard sur service desk

Novembre 2013. Regard sur service desk Novembre 2013 Regard sur service desk édito «reprenez le contrôle grâce à votre service desk!» Les attentes autour du service desk ont bien évolué. Fort de la riche expérience acquise dans l accompagnement

Plus en détail

Optimisation multi-critère pour l allocation de ressources sur Clouds distribués avec prise en compte de l énergie

Optimisation multi-critère pour l allocation de ressources sur Clouds distribués avec prise en compte de l énergie Optimisation multi-critère pour l allocation de ressources sur Clouds distribués avec prise en compte de l énergie 1 Présenté par: Yacine KESSACI Encadrement : N. MELAB E-G. TALBI 31/05/2011 Plan 2 Motivation

Plus en détail

Guillaume Garbey (Consultant sécurité) Contributeurs: Gilles Morieux, Ismaël Cisse, Victor Joatton

Guillaume Garbey (Consultant sécurité) Contributeurs: Gilles Morieux, Ismaël Cisse, Victor Joatton Guillaume Garbey (Consultant sécurité) Contributeurs: Gilles Morieux, Ismaël Cisse, Victor Joatton Lyon, le 25 février 2009 Introduction à la gestion des identités et des accès Enjeux et objectifs Les

Plus en détail

Interoperabilité entre Observatoire Virtuel et Grilles de calcul

Interoperabilité entre Observatoire Virtuel et Grilles de calcul Interoperabilité entre Observatoire Virtuel et Grilles de calcul J. Berthier, W. Thuillot & F. Vachier IMCCE / OBSPM / CNRS OV est une réponse de la communauté astronomique pour répondre aux besoins technologiques

Plus en détail

Définition et diffusion de signatures sémantiques dans les systèmes pair-à-pair

Définition et diffusion de signatures sémantiques dans les systèmes pair-à-pair Définition et diffusion de signatures sémantiques dans les systèmes pair-à-pair Raja Chiky, Bruno Defude, Georges Hébrail GET-ENST Paris Laboratoire LTCI - UMR 5141 CNRS Département Informatique et Réseaux

Plus en détail

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Mémoires 2010-2011 www.euranova.eu MÉMOIRES ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Contexte : Aujourd hui la plupart des serveurs d application JEE utilise des niveaux de cache L1

Plus en détail

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION THÈSE N O 2388 (2001) PRÉSENTÉE AU DÉPARTEMENT D'INFORMATIQUE ÉCOLE POLYTECHNIQUE FÉDÉRALE

Plus en détail

Thomas Loubrieu (Ifremer) Small to Big Data. http://wwz.ifremer.fr/bigdata. 26 Novembre 2013, Ifremer, Brest

Thomas Loubrieu (Ifremer) Small to Big Data. http://wwz.ifremer.fr/bigdata. 26 Novembre 2013, Ifremer, Brest Thomas Loubrieu (Ifremer) Small to Big Data 26 Novembre 2013, Ifremer, Brest http://wwz.ifremer.fr/bigdata Small to Big data IFREMER/IDM/ISI T. Loubrieu Résumé A partir d'expériences en gestion de données

Plus en détail

E-Biothon : Une plate-forme pour accélérer les recherches en biologie, santé et environnement.

E-Biothon : Une plate-forme pour accélérer les recherches en biologie, santé et environnement. E-Biothon : Une plate-forme pour accélérer les recherches en biologie, santé et environnement. N.Bard, S.Boin, F.Bothorel, P.Collinet, M.Daydé, B. Depardon, F. Desprez, M.Flé, A.Franc, J.-F. Gibrat, D.

Plus en détail

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D NOVA BPM «Première solution BPM intégr grée» Pierre Vignéras Bull R&D Définitions Business Process Pratiques existantes qui permettent aux personnes et systèmes de travailler ensemble Business Process

Plus en détail

A. À propos des annuaires

A. À propos des annuaires Chapitre 2 A. À propos des annuaires Nous sommes familiers et habitués à utiliser différents types d'annuaires dans notre vie quotidienne. À titre d'exemple, nous pouvons citer les annuaires téléphoniques

Plus en détail

Release Notes POM v5

Release Notes POM v5 Release Notes POM v5 POM Monitoring http://www.pom-monitoring.com Ce document est strictement réservé à l usage de la société POM Monitoring. Il ne peut être diffusé ou transféré sans l autorisation écrite

Plus en détail

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

LES APPROCHES CONCRÈTES POUR LE DÉPLOIEMENT D INFRASTRUCTURES CLOUD AVEC HDS & VMWARE

LES APPROCHES CONCRÈTES POUR LE DÉPLOIEMENT D INFRASTRUCTURES CLOUD AVEC HDS & VMWARE LES APPROCHES CONCRÈTES POUR LE DÉPLOIEMENT D INFRASTRUCTURES CLOUD AVEC HDS & VMWARE Sylvain SIOU VMware Laurent DELAISSE Hitachi Data Systems 1 Hitachi Data Systems Corporation 2012. All Rights Reserved

Plus en détail

Introduction 3. GIMI Gestion des demandes d intervention 5

Introduction 3. GIMI Gestion des demandes d intervention 5 SOMMAIRE Gestion Help Desk de - parc Service Desk Introduction 3 GIMI Gestion des demandes d intervention 5 1 Schéma de principe et description des rôles 6 2 Principe de fonctionnement 8 Interface Demandeur

Plus en détail

Chapitre 9 : Informatique décisionnelle

Chapitre 9 : Informatique décisionnelle Chapitre 9 : Informatique décisionnelle Sommaire Introduction... 3 Définition... 3 Les domaines d application de l informatique décisionnelle... 4 Architecture d un système décisionnel... 5 L outil Oracle

Plus en détail

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 SAS Cost and Profitability Management, également appelé CPM (ou C&P), est le nouveau nom de la solution SAS Activity-Based Management. Cette version

Plus en détail

Accélérateur de votre RÉUSSITE

Accélérateur de votre RÉUSSITE Accélérateur de votre RÉUSSITE SAP Business Objects est une suite décisionnelle unifiée et complète qui connecte ses utilisateurs en éliminant les difficultés d accès à l information. Mobile Devices Browsers

Plus en détail

Cloud Computing : quels intérêts et quelles solutions pour les développeurs?

Cloud Computing : quels intérêts et quelles solutions pour les développeurs? Cloud Computing : quels intérêts et quelles solutions pour les développeurs? Jérôme PANSANEL Directeur technique France Grilles JDEV 2015 BORDEAUX Sommaire Cloud Computing

Plus en détail

Disponibilité et fiabilité des services et des systèmes

Disponibilité et fiabilité des services et des systèmes Disponibilité et fiabilité des services et des systèmes Anthony Busson Introduction Un site Web commercial perd de l argent lorsque leur site n est plus disponible L activité d une entreprise peut être

Plus en détail

Garantir une meilleure prestation de services et une expérience utilisateur optimale

Garantir une meilleure prestation de services et une expérience utilisateur optimale LIVRE BLANC Garantir une meilleure prestation de services et une expérience utilisateur optimale Mai 2010 Garantir une meilleure prestation de services et une expérience utilisateur optimale CA Service

Plus en détail

Big data et sciences du Vivant L'exemple du séquençage haut débit

Big data et sciences du Vivant L'exemple du séquençage haut débit Big data et sciences du Vivant L'exemple du séquençage haut débit C. Gaspin, C. Hoede, C. Klopp, D. Laborie, J. Mariette, C. Noirot, MS. Trotard bioinfo@genopole.toulouse.inra.fr INRA - MIAT - Plate-forme

Plus en détail

mieux développer votre activité

mieux développer votre activité cloud computing mieux développer votre activité Les infrastructures IT et les applications d entreprise de plus en plus nombreuses sont une source croissante de contraintes. Data centers, réseau, serveurs,

Plus en détail

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration Julien MATHEVET Alexandre BOISSY GSID 4 Rapport Load Balancing et migration Printemps 2001 SOMMAIRE INTRODUCTION... 3 SYNTHESE CONCERNANT LE LOAD BALANCING ET LA MIGRATION... 4 POURQUOI FAIRE DU LOAD BALANCING?...

Plus en détail

SHAREPOINT PORTAL SERVER 2013

SHAREPOINT PORTAL SERVER 2013 Powered by TCPDF (www.tcpdf.org) SHAREPOINT PORTAL SERVER 2013 Sharepoint portal server 2013 DEVELOPING MICROSOFT SHAREPOINT SERVER 2013 CORE SOLUTIONS Réf: MS20488 Durée : 5 jours (7 heures) OBJECTIFS

Plus en détail