Calculs intensifs pour l étude de l’évolution

Présentation au sujet: "Calculs intensifs pour l étude de l’évolution"— Transcription de la présentation:

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

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

3 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

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

5 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

6 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 : 12 ans En 2010 : projet « 1000 Génomes » (1000 génomes humains)

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

8 L’évolution « rien en biologie n’a de sens, si ce n’est à la lumière de l’évolution » Theodosius Dobzhansky ( ) : 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

9 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

10 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

11 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

12 La phylogénie Phylogénie des êtres vivants

13 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

14 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

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

16 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

17 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 »

18 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.

19 HOGENOM Base de données de familles de gènes homologues pour tous les génomes
Environ 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 familles

20 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

21 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

22 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

23 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

24 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 »)

25 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»)

26 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»)

27 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»)

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

29 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.

30 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

31 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

32 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

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

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

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

36 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

37 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 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 séquences BLAST 6,000,000 nouvelles x 6,000,000 nouvelles [cluster] BLAST 6,000,000 nouvelles x 13,000,000 anciennes [cluster]

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

39 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

40 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

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

42 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

43 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

44 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

45 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

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

47 Lancement des jobs Launcher : Le launcher propose une liste de noeuds.
script jdl Launcher : source launcher 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

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

49 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 = moyenne : jobs de 15 heures Calcul en 1 semaine au lieu de 8 ans

50 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 à N x 100 Boucle: pour i variant de (N -1)x à 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

51 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

52 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

53 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

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

55 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

56 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 à N x 100 Boucle: pour i variant de (N -1)x à 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

57 Mise en place sur TIDRA 2ème release
Résultats Production par « bloc » de 1000 jobs paramétriques, avec 20 fichiers par job soit fichiers traités. 9 « blocs » de 1000 job à lancer pour traiter les 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 ,535 Production ,174 Production ,835

58 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

59 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

60 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

61 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

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

63 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

64 Perspectives TIDRA Fusion DTM et JJS

65 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

66 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

67 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

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

69 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

70 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

71 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

72 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

73 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

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

75 Temps de calcul GRISBI et TIDRA
TIDRA 1ère production jobs heures ( 13 ans) sur 1 processeur Intel Xeon. TIDRA 2 ème production jobs (répartis sur une dizaine de soumissions) heures ( 7 ans) sur 1 processeur Intel Xeon. pics de 650 jobs en parallèle GRISBI avec et sans XtreemFS job heures ( 1 an) sur 1 processeur Intel Xeon  pics de 830 jobs en parallèle

76 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