Calculs intensifs pour l étude de l’évolution Le calcul de l’arbre du vivant

Le génome Le génome est l’ensemble du materiel génétique d’un individu ou d’une espece Le génome est codé sous la forme de une ou plusieurs molécules d’ADN (par exemple les chromosomes) Il est présent chez tous les organismes vivants: plantes, animaux, insectes, champignons, microbes, bactéries Toutes les cellules d’un individu contienent un exemplaire du génome (chaque cellule humaine contient 2 mètres d'ADN environ)

Les gènes Il s’agit de zones dans le génome qui contiennent l’information sur la construction d’élements fondamentaux du fonctionnement des cellules, des organes, etc. Par exemple les gènes codent pour les protéines, des polypeptides impliqués a tous les niveaux de la vie cellulaire

Diversité des génomes Génome humain : Génome de la mouche: 3,2 milliards de lettres environ 25 000 gènes Génome de la mouche: 120 millions de lettres environ 20 000 gènes Génome du maïs: 5 milliards de lettres 55 000 gènes Génome de la bactérie Escherichia coli 4 millions de lettres 4 000 gènes

Séquençage du génome Il s’agit de connaître la « séquence » du génome c’est à dire la formule : AATGCATAGTGCCGATG….. Certaines parties du génome sont des gènes qui codent des protéines AATGCATAGTGCCGATGTAGTGCATAGTGC

Explosion du nombre de génomes séquencés Cout du séquençage en chute libre (nouvelles technos) Accélération du nombre de génomes séquencés Génome de l’homme: Séquencage du génome humain 1989-2001: 12 ans En 2010 : projet « 1000 Génomes » (1000 génomes humains)

Explosion du nombre de génomes séquencés 2 000 génomes disponibles aujourd’hui Quelque projets parmi d’autres: Génome 10K: 10 000 génomes de vertébrés i5K: 5 000 génomes d’insectes dans les 5 ans 1KP: 1 000 génomes de plantes

L’évolution « rien en biologie n’a de sens, si ce n’est à la lumière de l’évolution » Theodosius Dobzhansky (1900-1975) : La diversité des formes de vie est le résultat d’un processus historique, fait de hasards et de contraintes : l’évolution Comprendre l’évolution pour expliquer les formes de vie Comprendre les formes de vie pour retracer l’évolution

La phylogénie Etude de l’histoire des relation de parentés entre les êtres vivants Anatomie comparée Comparaison de séquence On observe une similarité qui permet de supposer qui il existait un ancêtre commun a ces organes On peut observer des similarités entre les séquences intérêt: tous les organismes ont des séquences d’ADN (alors qu’ils n’ont pas tous des pattes!) AATTACGATCGATTTACGC AATTGCGATCGATTTACGC AATTCCTATCGATTTACGC

La phylogénie Gènes homologues: ce sont des gènes qui descendent du même gène ancestral Deux séquences présentant une forte similarité de séquence ont de grande chance d’être des séquences homologues Nombreuse méthodes mathématique permettant de calculer la similarité entre 2 séquences Séquences ADN : 4 lettres Séquences de protéines : 20 lettres

La phylogénie Phylogénie d’un gène On estime la distance évolutive entre différents gènes On la représente sous la forme d’un arbre Phylogénie d’un gène présent dans le génome de différents organismes Ces gènes sont des gènes « homologues » Le gène de la souris est plus proche du gène du rat que de celui de la vache : la distance entre gène est proportionelle la longeur de branche

La phylogénie Phylogénie des êtres vivants

La phylogénie Phylogénie des êtres vivants On utilise la phylogénie d’un gène pour proposer une phylogénie des êtres vivants

La génomique comparative Autrefois on se basait sur quelques gènes pour reconstruire l’ histoire évolutive des organismes Mais tous les gènes n’ont pas la même histoire Aujourd’hui on peut utiliser l’ensemble du génome pour comparer les organismes

La phylogénomique Calcul de la phylogénie des especes en se basant sur l’ensemble de leur génome

Projet Ancestrome Etude du fonctionnement et de l’organisation des génomes des êtres vivants actuels dans le but de construire des modèles permettant de connaître le génomes de leurs ancêtres ainsi que les processus évolutifs qui les ont engendrés Entre autres aspects: Base de données HOGENOM Calculs de similarité de séquences Clustering Programme PHYLDOG : Calcul simultané de l’arbre phylogénetique du vivant et des arbres phylogenétique de chaque gène

HOGENOM Base de données de familles de gènes homologues pour tous les génomes On recherche les familles de gènes homologues chez tous les organismes vivants Pour chaque famille on calcule un arbre phylogénétique: un « arbre de gène »

HOGENOM Base de données de familles de gènes homologues pour tous les génomes génomes (tout l’ADN)  gènes (ADN codant)  protéines (traduction du gène) génomes protéines clustering phylogénie etc.

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Environ 1 500 génomes (dont 140 eukaryotes : mamiferes, oiseaux, plantes etc.) Soit 160 milliards de lettres au total Environ 7 millions de gènes codants soit 3 milliards de lettres Résultat: ces 7 milions de gènes sont classés en 300 000 familles

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines

Recherche de similarités locales entre les séquences HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines Recherche de similarités locales entre les séquences (« BLAST »)

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines Recherche de similarités locales entre les séquences (« BLAST ») Clustering transitif avec condition (« SILIX»)

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines A B A C A D Recherche de similarités locales entre les séquences (« BLAST ») Clustering transitif avec condition (« SILIX»)

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Construction des familles de gènes homologues génomes protéines A B A B A C C D Famille A D Recherche de similarités locales entre les séquences (« BLAST ») Clustering transitif avec condition (« SILIX»)

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Marche à suivre génomes

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Marche à suivre clustering phylogénie génomes protéines etc.

Calcul distribué Parallélisation par les données texte banque BLAST Plusieurs millions de séquences « requêtes » 1 fichier Plusieurs millions de séquences « cibles » Plusieurs milliards de zones similaires entre les séquences

Calcul distribué Parallélisation par les données texte banque BLAST Plusieurs millions de séquences « requêtes » 1 fichier Plusieurs millions de séquences « cibles » Plusieurs milliards de zones similaires entre les séquences texte banque BLAST Quelques dizaines séquences « requêtes » Centaines de milliers de fichiers

Calcul distribué Parallélisation par les données Chaque calcul est indépendant On peut donc utiliser indifféremment et indépendamment un cluster de machines une grille de calcul le calcul dans le nuage une combinaison des précédents

Calculs BLAST incrémentiel sur toutes les séquences connues A chaque nouvelle version de la base, on classe les séquences comme « ancienne » ou « nouvelle » On calcule la similiarité: des nouvelles séquences entre-elles ( BLAST new x new) des nouvelles séquences avec les anciennes ( BLAST new x old) Finalement on ajoute BLAST new x new et BLAST new x old aux similarités de la release précédente (i. e. BLAST old x old)

Calculs BLAST incrémentiel sur toutes les séquences connues Release Nombre de séquences BLASTS 1 (2009) 7 000 000 7 000 000 x 7 000 000 2 (2011) 13 000 000 6 000 000 x 6 000 000 6 000 000 x 7 000 000 3 (2013) 19 000 000 6 000 000 x 6 000 000 6 000 000 x 13 000 000

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Comparaison de tous les gènes entre eux pour déterminer leur similarité Utilisation d’un logiciel (« BLAST ») qui recherche des zones de similarités locales entre les séquences ( approche heuristique)

HOGENOM Base de données de familles de gènes homologues pour tous les génomes Exemple: un arbre phylogénetique de gène de HOGENOM Eukaryotes

Calculs effectués 1ère Release (2009-2010) env. 8 000 000 séquences BLAST 8,000,000 x 8,000,000 séquences [grille TIDRA] 2ème Release (2011) env. 13 000 000 séquences BLAST 5,000,000 nouvelles x 5,000,000 nouvelles [cluster] BLAST 5,000,000 nouvelles x 8,000,000 anciennes [grilles TIDRA/GRISBI] 3ème Release (2013) env. 19 000 000 séquences BLAST 6,000,000 nouvelles x 6,000,000 nouvelles [cluster] BLAST 6,000,000 nouvelles x 13,000,000 anciennes [cluster]

Technologie grille et services associés sur TIDRA (Grille Rhône-Alpes) 7000 cœurs (cpu) 300 To de stockage 5 Sites LAPP (Annecy) LPSC (Grenoble) IPNL (Lyon) IBCP (Lyon) CC-IN2P3 ( Lyon)

Technologie grille et services associés TIDRA RAGRID (Grille Rhône-Alpes) Middleware : Job management : gLite, LRMS Stockage : iRODS, SRM Utilisateur : JSAGA implementation SAGA vo.rhone-alpes.idgrilles.fr

Mise en place sur TIDRA 1ère release (2009-2010) 1ère mouture de BGENR : séquences Uniprot (9 millions) 8 millions de séquences non redondantes à comparer. Historique : Mise en place de l’outil avec 3 membres du CC - Y.Cardenas, P. Calvat, J.Y. Nief 1er contact avec la grille Novembre 2008 Premiers tests de charge et développements blast  intensifs   Février 2009  Arrivée de iRODS Gros soulagement!!! Juin 2009 Début de la production + développement Juillet 2009 Fin de la production Janvier 2010

Contraintes dues à la mémoire Mémoire minimum des machines : 2 Go La solidité d'une chaîne dépend du maillon le plus faible : on veut éviter un dépassement de mémoire sur les machines les moins puissantes taille maximum de la banque BLAST : 2 x 106 séquences 8 x 106 = 4 banques de 2 x 106 séquences à traiter itérativement * nombre maximum de séquences à traiter avec une banque 2 x 106 : 30 La “tâche unitaire” compatible avec une mémoire de 2 Go est donc : 4 x BLAST de 30 séquences vs 2 x 106 séquences *La taille théorique de la banque BLAST est fixée (option -z)

Optimisation du temps passé en calcul Le calcul d’1 tâche unitaire est très court : env. 15 minutes Bien inférieur au temps disponible dans un job : variable selon les machines quelques heures - quelques jours Chaque job doit exécuter le plus grand nombre possible de tâches unitaires

Résumé Données ( format FASTA) Banque BLAST Séquences à blaster 1ère mouture de BGENR : séquences Uniprot (9 millions) : 8 millions non redondantes. Banque BLAST 8 millions de séquences Divisée en 4 bases de 2 millions de séquences pour éviter de dépasser la mémoire maximum disponible sur les machines Séquences à blaster 8 millions de séquences, soit: 250, 000 fichiers de 30 séquences au format FASTA 30 séquences : nombre maximum de séquences pour éviter un dépassement de mémoire sur les machines les moins puissantes Chaque job doit exécuter le plus grand nombre possible de tâches quelque soit son temps de calcul maximum

Stratégie adoptée Plusieurs tâches par job 1 - Liste de tâches à effectuer (250,000 fichiers de 30 séquences) 2 - Chaque job N tente de traiter les 100 tâches à partir de la tâche numéro N x 100 3 - Une fois tous les jobs terminés, génération d’une nouvelle liste de tâches à traiter 4 - Retour au point 1 On a choisi un “pas” de 100 fichiers par job : c’est au dessus du nombre de tâches qu’il est possible de traiter avec les durées les plus longues. Mais on peut l’adapter à la production : vers la fin, on prend un “pas” plus court On utilise des jobs paramètriques, le paramètre est N

Stratégie deuxième production première production 1 1 1 1 100 100 100 200 200 200 200 300 300 300 300 400 400 400 400

Paramètres à ajuster: exemple BGENR1 : 8 x 106 séquences 1 - Nombre de banques BLAST 4 2 - Nombre de séquences par fichiers 30 3 - Nombre max de fichiers par job 100 4 - Nombre de jobs par job paramétrique 40 5 - Délai entre la soumission des jobs paramétriques 20 mn

Lancement des jobs Launcher : Le launcher propose une liste de noeuds. script jdl Launcher : source launcher 1 1000 40 20 generic_par_irods_lst_new.jdl premier job dernier job nombre de jobs par job paramétrique délai de soumission entre les jobs Le launcher propose une liste de noeuds. Les jobs paramétriques seront répartis sur les noeuds choisis. Ici on a lancé 1000 jobs (de 1 à 1000) par paquets de 40 : 25 jobs paramétriques, temps total soumission = 8h

Monitoring Un job de monitoring est lancé qui envoie régulièrement des mails décrivant l’avancement des tâches

Résultats Rappel : 250,000 fichiers à traiter  250,000 fichiers résultats 2,000,000,000 hits blast concaténation en 200 fichiers de 5 Go (1 To) moyenne de 50 fichiers par job environ 5000 jobs (plusieurs séries) moyenne : 125 jobs x 40 paramétriques x 50 fichiers = 250 000 moyenne : jobs de 15 heures Calcul en 1 semaine au lieu de 8 ans

Description du JDL N est le paramètre du job paramétrique Déroulement d’un job numéro N : récupération de différents outils via lcg-cp : outils iRODS outils pour l’estimation du temps de calcul outils pour la gestion des proxies Renouvellement du proxy Lancement de l’application : Copie des programmes BLAST en local via iRODS Copie des banques BLAST en local via iRODS Copie de la liste de fichiers à traiter Copie des 100 fichiers à traiter : fichiers numéros (N -1)x 100 +1 à N x 100 Boucle: pour i variant de (N -1)x 100 +1 à N x 100 traite le fichier i, copie le résultat via iRODS tant que 95% du temps maximum n’est pas atteint, passe au fichier suivant Post-traitement: envoi de mail, copie des logs via iRODS

Mise en place sur TIDRA 2ème release (2011) 2ère mouture de BGENR : séquences Uniprot + Ensembl + Autres (33 millions de séquences, 12 millions non redondantes) 5 millions de séquences non redondantes, soit 170,000 fichiers de 30 séquences à comparer avec 7 millons de séquence. Nouveaux développements : Outil DTM - Outil JJS - Acces iRODs

Mise en place sur TIDRA 2ème release Prototype du DTM (« Distributed Task Manager ») Yonny Cardenas gLite + iRODS système de base de données pour la gestion des jobs (runing, ended, canceled,etc.). destination des jobs : à la fois en local, BQS et Grille gestion automatisée de la production (gestion des erreurs, etc.) l’utilisateur fournit seulement une liste de tâches, DTM s’occupe des jobs et de la production Pour l’instant fonction uniquement pour BQS, adaptation a la grille en cours

Mise en place sur TIDRA 2ème release JJS Java Job Submission (Pascal Calvat) commande « jjs-* » pour simplifier l’utilisation de la grille : soumission monitoring gestion des proxy gestion automatique de la répartition des jobs sur les noeuds de la grille, analyse de l’efficacité des différents noeuds fonctionne via des jdl crées a partir d’un template avec une commande jjs Notion de « production » c-à-d d’un ensemble de job

Mise en place sur TIDRA 2ème release Migration totale de nos données sur iRODS: accès direct aux données : icd,ils,ipwd,iput,iget,etc. programme de recherche des hits blast via iRODS (utilisation d’une API C pour iRODS) utilisation des meta-données et des micro-services ( à développer)

Mise en place sur TIDRA 2ème release Approche similaire Release 1, mais irods intégré à la grille ( plus besoin de récupérer les utilitaire irods ) gestion des proxies intégrée ( plus besoin de déclarer les proxies dans le script) Utilisation des commandes jjs ( plus de jobs paramétriques) Plus simple : 1 jdl + 1 script

Description du JDL avec JJS N est le paramètre du job paramétrique Déroulement d’un job numéro N : récupération de différents outils via lcg-cp X: outils iRODS X outils pour l’estimation du temps de calcul X outils pour la gestion des proxies X Renouvellement du proxy X Lancement de l’application : Copie des programmes BLAST en local via iRODS Copie des banques BLAST en local via iRODS Copie de la liste de fichiers à traiter Copie des 100 fichiers à traiter : fichiers numéros (N -1)x 100 +1 à N x 100 Boucle: pour i variant de (N -1)x 100 +1 à N x 100 traite le fichier i, copie le résultat via iRODS tant que 95% du temps maximum n’est pas atteint, passe au fichier suivant X Post-traitement: envoi de mail, copie des logs via iRODS

Mise en place sur TIDRA 2ème release Résultats Production par « bloc » de 1000 jobs paramétriques, avec 20 fichiers par job soit 20 0000 fichiers traités. 9 « blocs » de 1000 job à lancer pour traiter les 170 000 fichiers Qualité: un proxy de 5 jours permet de perdre moins de jobs Production jobs jobs récuperés jobs OK nb fichiers traités Production 7 1000 734 411 10,535 Production 8 1000 881 676 17,174 Production 9 1000 982 786 19,835

Problèmes rencontrés Beaucoup de choses à installer sur les machines En général Beaucoup de choses à installer sur les machines Hétérogénéité des machines Information fournie par les machines au WMS pas toujours suffisante

Problèmes rencontrés Si trop de jobs soumis à la fois Solution Saturation Si trop de jobs soumis à la fois saturation du WMS saturation des commandes «iget» de iRODS Solution limiter le nombre de jobs qui attaquent en même temps jouer sur le nombre de job paramétriques par job délai aléatoire au début de chaque job entre les jobs

Problèmes rencontrés Temps de calcul d’un job Estimation du temps de calcul d’un job pour un arrêt «propre» : système hétérogène, dépend des nœuds Solution Release 1 : test de la présence d’un outil pour estimer le temps de calcul Release 1 : récupération d’un outil si besoin Release 2 : pas encore de solution, à améliorer

Problèmes rencontrés Renouvellement des proxies RELEASE 1 : 2 types de problèmes La soumission dure trop longtemps, on perd le proxy utiliser un serveur de proxies Le job dure trop longtemps, on perd le proxy car la grille ne gère pas le renouvellement automatique du proxy le job doit renouveler lui-même le proxy au départ. RELEASE 2 : plus de problèmes. Proxies de 5 jours, outil myProxy

Conclusion TIDRA BGENR Release 1 et 2 travail pionnier dans l’utilisation en production de iRODS avec gLite 2 technologies/middleware integrées de manière transparente gLite (EGEE) pour le calcul iRODS pour le stockage Après ajustement iRODS semble bien supporter la charge ( à hauteur de 500 jobs en parallèle)

Intérêt d’une grille régionale Pas trop de nœuds (pas l’embaras du choix, connaissance des capacités des nœuds) En cas de problème sur un nœud, forte réactivité, facile de contacter un responsable

Perspectives TIDRA Fusion DTM et JJS

Mise en place sur GRISBI Outils disponibles Tous les outils nécessaires à la bioinformatique sont disponible (tags) Les bases de données biologiques sont disponible (tags) Logiciel de statistique R installé (tags) Systême de fichiers XtreemFS : répertoire partagé en réseau par tous les jobs de grille lié au proxy, totalement transparent grmount : montage temporaire du répertoire grmount -u : démontage

Parallélisation par les « queries » Meme approche que TIDRA données fasta banque BLAST 8 106 8 106 QUERY SUBJECT banque BLAST 8 106 QUERY SUBJECT

Technologie grille et services associés sur GRISBI 856 cœurs (cpu) 25 To de stockage 7 Sites IBCP (Lyon) LBBE (Lyon) ABiMS (Roscoff) GenOuest (Rennes) CBiB ( Bordeaux) GenoTool (Toulouse) Outils bioinformatiques Bases de données biologiques XtreemFS

Stratégie « 1 job = 1 tâche » (sans XtreemFS) On utilise les outils disponibles sur la grille (blast) On dépose sur la grille la base de données blast à traiter (LFC) Fichier d’entrée en local, définis par le jdl (SandBox) Fichier de sortie en local, définis par le jdl (SandBox)

Description du JDL GRISBI « 1 job = 1 tâche » InputSandBox: le fichier à traiter OutputSandBox: le résultat N est le paramètre du job paramétrique, Déroulement d’un job numéro N : Copie des banques BLAST en local (lcg-cp ) Traitement du fichier numéro N 170,000 fichiers à traiter : 170,000 jobs paramètriques ici 1 job = 1 fichier Essais sur une production de 1000 jobs parametriques 200 a 400 jobs en run simultanés

Stratégie « 1 job = 1 tâche » (sans XtreemFS) Ca marche, mais: Très grand nombre de jobs On utilise la SandBox pour les sorties : Taille des sorties importantes, risque de limitation! Pas très efficace ( temps de calcul court, on récupère la base blast pour chaque tâche, etc.) On souhaiterais utiliser une approche similaire à celle utilisée dans TIDRA avec une liste de tâches comme argument du jdl: Pas possible avec la SandBox

Stratégie « 1 job = n tâches » (avec XtreemFS) On utilise les outils disponibles sur la grille (blast) On dépose sur la grille la base de données blast à traiter (LFC) On dépose sur la grille tous les fichier d’entrées (XtreemFS) Chaque jobs traite plusieurs fichiers d’une liste (fournie par la SandBox) On stocke sur la grille les fichiers de sortie via XtreemFS 170,000 fichiers à traiter ici 1 job = 30 tâches ( = 30 fichiers soit 90 séquences) Production : 6 soumissions par paquets de 1000 jobs parametriques on atteint 850 jobs en run simultanés

Description du JDL GRISBI/XtreemFS InputSandBox: liste des fichiers à traiter N est le paramètre du job paramétrique, m est le nb de fichiers à traiter par job m fichiers à traiter : fichiers numéros (N -1)x m +1 à N x m Déroulement d’un job numéro N : Copie des banques BLAST en local (lcg-cp ) Boucle: pour i variant de (N -1)x m +1 à N x m Montage du répertoire grille Vérifie si le fichier i a été calculé: si oui, saute à i +1 Copie du fichier i Démontage du répertoire grille Traite le fichier i avec blast, Copie du résultat Démontage du repertoire grille Fin de boucle 170,000 fichiers à traiter ici 1 job = 30 tâches ( 30 fichiers soit 90 séquences) Production : 6 soumissions par paquets de 1000 jobs parametriques on atteint 850 jobs en run simultanés Entrées et sorties sur XtreemFS

Problèmes rencontrés GRISBI Tags inexacts Information fournie par les machines au WMS pas toujours suffisante Saturation des accès XtreemFS Problèmes résolus sans difficultés

Conclusion GRISBI Travail pionnier dans l’utilisation en production de XtreemFS avec gLite 2 technologies/middleware integrées gLite (EGEE) pour le calcul XtreemFS pour le stockage Après ajustement XtreemFS semble bien supporter la charge ( à hauteur de 500 jobs en parallèle)

Temps de calcul GRISBI et TIDRA TIDRA 1ère production 22 248 jobs 115 751 heures ( 13 ans) sur 1 processeur Intel Xeon. TIDRA 2 ème production 15 797 jobs (répartis sur une dizaine de soumissions) 63 433 heures ( 7 ans) sur 1 processeur Intel Xeon. pics de 650 jobs en parallèle GRISBI avec et sans XtreemFS 47 713 job 8 810 heures ( 1 an) sur 1 processeur Intel Xeon  pics de 830 jobs en parallèle

CONCLUSIONS TIDRA vs GRISBI Différences TIDRA GRISBI Généraliste Bioinformatique Régionale Nationale Pas de softs/BDD installés Logiciels et BDD bioinfo et biostats disponibles Gestion des données avec iRODS Gestion des données XtreemFS Commandes jjs* Commandes gri* DTM+JJS (en devéloppement) Gestion des tâches Adapté à des grandes productions Adapté a des calculs de bioinfo/biostats classiques Points communs Pas trop de nœuds (pas l’embaras du choix, connaissance des capacités des nœuds) En cas de problème sur un nœud, forte réactivité, facile de contacter un responsable Commandes « grilles » simplifiées