[Crac-bugs] Fwd: Re: Consommation mémoire

Nicolas PHILIPPE nicolas.philippe at inserm.fr
Sam 15 Mar 17:44:20 CET 2014


Bonjour Mathieu,

Tout d'abord, désolé pour cette réponse tardive.
Ensuite, je vais directement répondre dans le corps du message.

Le 24/02/2014 16:26, Mikaël Salson a écrit :
>
>
> -------- Original Message --------
> Subject: 	Re: [Crac-bugs] Consommation mémoire
> Date: 	Mon, 24 Feb 2014 15:03:57 +0100
> From: 	Mathieu Bahin <mbahin at univ-rennes1.fr>
> To: 	Mikaël Salson <mikael.salson at lifl.fr>
>
>
>
> Bonjour,
>
> Merci pour ta précédente réponse qui répondait bien à mes questions.
>
> Je commence à faire quelques tests d'utilisation de CRAC dans le cadre
> de la détection de chimères. J'avais plusieurs interrogations à ce sujet.
>
> Si je résume ce que j'ai compris du fonctionnement de CRAC (avec ses
> paramètres par défaut).
> Chaque read est coupée en tous les k-mers possibles selon la taille de
> k-mer demandée en paramètre.
> Chacun de ces k-mer est mappé sur le génome de référence, la read a un
> mapping :
>    - "unique" si au moins 0,15% de ses k-mers mappent
>    - "duplicate" si il a entre  2 et 9 locations
>    - "multiple" au-delà de 9 locations
> Les location et support profiles sont créés et les reads sont annotées.
>
> Dans ce cas, quel est le mapping retenu pour les reads "duplicate" ? Le
> plus "probable" ?
Alors si le read est dupliqué, on donne le mapping du premier qui vient 
dans le FM-index.
Dans la prochaine release de CRAC, il est prévu de sortir toutes les 
localisations <= max_locs pour Duplicate et Multiple car il est vrai que 
cela peut poser des problèmes, par exemple lors de la visualisation du BAM.
Après, peut-être que l'on pourrait aussi proposer une option --best 
comme le fait bowtie. Mais dans ce cas, je ne vois pas quels critères on 
pourrait utiliser pour ne sortir que la localisation la plus probable.
>
> Dans le additional_file2 de l'article, on retrouve 5 sous-catégories de
> chimères (quand on utilise "paired-end-chimera") alors qu'on en retrouve
> que 4 dans la documentation en ligne (chimera_flag). Et effectivement,
> dans les résultats que j'ai obtenu, les flags vont de 1 à 15. A priori,
> c'est la catégorie 5 de l'additional file 2 ("Exactly as in class 3, but
> the exons overlap each other by at least one nucleotide.") qui ne figure
> pas dans le guide en ligne.
Alors en effet, on a décidé de supprimer la catégorie 5 qui n'est en 
fait qu'une sous catégorie de la 3.
>
> Concernant ce "chimera_flag", je ne comprend pas comment on peut obtenir
> des flags avec la première et la dernière condition (ex: 11 ou 12)
> puisque ça nous dit à la fois que les reads sont sur les mêmes
> chromosomes et des chromosomes différents.
Oui, lorsqu'on a rajouté le "chimera_flag", on est allé un peu trop vite 
en besogne et on a oublié des petites conditions pour que les chimères 
soient classées en partition comme dans l'article. Cette erreur est 
corrigée dans la version de développement et, par la même occasion, elle 
le sera dans la prochaine release qui sortira dans une quinzaine de jours.

Sinon, nous avons développé dans les CRACtools 
(http://cractools.gforge.inria.fr/what-is-it/) un workflow dédié aux 
chimères de CRAC, qui permet notamment de les annoter à partir d'un 
fichier gff en entrée, de les catégoriser,  de leur attribuer un rank en 
fonction de différents filtres, de croiser les chimères "paired_ends" et 
les jonctions chimériques "single_reads", de mesurer la couverture de la 
chimère, etc... De plus, nous générons automatiquement un rapport en 
sortie avec des jolis graphiques en R.

Nous allons bientôt mettre à disposition le tar.gz de chimCT (qui n'est 
pas encore publié). Cependant, nous pouvons aussi en discuter par 
téléphone avec Jérôme (en cc), Thérèse (en cc) et Mikaël.  Nous ne 
serons pas disponibles avec Thérèse la semaine prochaine où je vais 
justement faire une présentation CRAC + chimCT à Paris (à Gustave 
Roussy). Je pense qu'à partir de la semaine du 24 mars, nous serons 
davantage disponibles.

> Mathieu Bahin
> IGDR - RENNES
Nicolas PHILIPPE
>
> On 7 févr. 14, at 17:10, Mikaël Salson wrote:
>
>> Bonjour,
>>
>> Merci pour ce retour.
>>
>>> Nous nous posions une question, la consommation mémoire est-elle
>>> linéaire (par rapport au petit exemple cité dans 'What is it ?') ? Nous
>>> travaillerons essentiellement sur des fichiers d'environ 80-100 millions
>>> de reads faisant 100 pb chacune. Cela dépend-t-il aussi de la taille du
>>> génome indexé ?
>> Oui elle est à peu près linéaire par rapport à la quantité de séquences
>> en entrée.
>> La consommation mémoire dépend aussi du génome, mais il ne joue qu'une
>> faible importance dans la consommation finale. Pour le génome du chien,
>> cela devrait représenter moins de 2Go en mémoire.
>>
>>> Je me permets de vous signaler une coquille (enfin je pense) sur le
>>> site. Dans la page 'Documentation of SAM format in CRAC', je pense qu'au
>>> point 3.6, vous avez mis 'XQ' au lieu de 'XO' dans la définition.
>> Effectivement merci, c'est corrigé.
>> D'ailleurs il y a un problème avec les informations affichés dans XQ
>> dans certaines conditions. C'est corrigé mais nous n'avons pas encore eu
>> le temps de diffuser la nouvelle version sur le site.
>> Elle peut être trouvée ici : http://crac.gforge.inria.fr/download/
>>
>> N'hésitez pas à nous tenir au courant des avancées.
>>
>> Mikaël.
>>> Cordialement,
>>> Mathieu BAHIN
>>> UMR6290
>>> RENNES
>>> _______________________________________________
>>> Crac-bugs mailing list
>>> Crac-bugs at lists.gforge.inria.fr <mailto:Crac-bugs at lists.gforge.inria.fr>
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/crac-bugs
>>>
>
>
>
> _______________________________________________
> Crac-bugs mailing list
> Crac-bugs at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/crac-bugs




More information about the Crac-bugs mailing list