Longueur des reads d'un clone, prendre tous les reads en compte
La longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en être très loin).
Problème : on peut avoir des chimères, et elles vont se trouver parmi les premières séquences considérées. Par exemple, la fameuse séquence de Yann (patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11 clone TRDV101 -5/0/-3 TRDD201 -1/0/-7 TRAJ29*01), sur ma machine j'ai une représentative de 257 bp (58% of 438 bp). On pourrait se dire : c'est moche. En fait non.
On va dans le tableau de Yann et la taille en électrophorèse est 255 !
Bilan : il faudrait calculer la taille sur les reads stockés. Le BinReadStorage peut donner l'info (il peut même donner l'info pour tous les reads et pas seulement pour ceux qu'il stocke). Maintenant qu'on propose le coverage comme un axe d'analyse en disant que c'est une bonne mesure de la qualité, c'est assez critique comme problème.
De mémoire, n'est-ce pas sur l'ensemble des 2000 premiers reads ? Est-ce que ce 2000 ne devrait pas atténuer les quelques chimères au début ? Est-ce que cela signifie, pour la séquence de Yann, que de nombreux reads chimériques sont là ?
Cela dit, même si c'est le cas, quand on a beaucoup de reads, les 2000 premiers peuvent faire sens "les plus gros"... Mais les résultats donc ne sont plus cohérents entre un gros clone 20 000 reads et un petit 2 000.
Donc tu as sans doute raison, il faudra faire cette moyenne sur tous les reads. Mais alors la coverage pourra être bien au-dessus de 1.00, s'il y a des petits reads...
Ben non, c'est pas sur les 2000 premiers… j'ai regardé dans le code. Tu avais mis le calcul de la longueur dans la boucle qui calcule la représentative. Mais pour le calcul de la représentative je ne parcours pas tous les reads. Je m'arrête au read qui m'a donné la meilleure représentative + stability_limit (30 par défaut).
Argh.
(Et j'ai donc mal répondu à Yann tout à l'heure.) Et oui, ce serait bien de le faire sur l'ensemble des reads via BinReadStorage. Idéalement instancier un objet Stats par BinReadStorage, cela permettra d'avoir plus que la longueur si un jour Stats fait mieux (la distribution par exemple)
Notons que le "av. len" dans les infos du run est lui bien calculé, sur toutes les reads (windowExtractor.cpp:57)
Finalement le Stats est instancié dans windows.cpp : stats_by_windows, de la même manière que germline_by_windows, status_by_windows et seqs_by_windows.
(On devrait faire du ménage là-dedans, et bouger tous ces trucs dans le BinReads ?)
J'ai bien vu qu'il y avait aussi des calculs de longueur dans BinReads, on aurait pu le faire avec (voir tâche Stats / BinReads), mais je maîtrisais mieux l'autre côté :-)
Il y a quelque chose qu'on n'utilise pas assez dans producteev c'est le « in progress ». Avant d'aller manger j'avais un code qui faisait ça (en passant par BinReadStorage), mais qui ne compilait pas encore. Ni moi, ni toi n'avons utilisé le « in progress », d'où le doublon.
oui, tout à fait.
désolé...