Taille de fenêtre en IGH : cas où 50 ne suffit pas ?
La taille des fenêtres en multi-système est globale. À rajouter dans germlines et voir les implications dans windowExtractor ou la représentative.
On remet donc le doigt dessus. C'est embêtant si on est amené à comparer des données produites par des configs différentes.
Au minimum : rajouter dans germline, pour qu'en multi IGH soit aussi à 60. Ou sinon, grande homogénéisation, tout le monde à 40, 50, ou 60.
On pourrait décider de cela avant 2015.02. Je penche pour la grande homogénéisation.
à décider pour 2015.02
ok, on voit cela pour 2015.04
plus tard...
Au fait, j'ai bien vu hier que la propagande officielle indique "50" partout :)
2d80348c, 50 pour tout le monde. Il n'y a "plus" que la transition server à voir, autre tâche.
Euh… c'est pas un peu dangereux de mettre ça sur master alors qu'on n'a pas de moyen de faire la transition ? Ça veut dire qu'il ne faut surtout pas changer la version de vidjil sur rbx
rbx est sur 2015.04, sur un version stable, oui il faudra faire attention à ne pas changer tout de suite... master sert à cela :)
au passage, master est désynchronisé avec rbx depuis déjà quelque temps , surtout avec le -e 1.0 par défaut mais aussi le -t 100
50bp, est-ce bien raisonnable ? Oui je sais on n'a plus ou moins tranché mais sans vraiment avoir de recul sur des données.
Mais quand je vois ça : http://rbx.vidjil.org/browser/?patient=481&config=26 (clone à 1,5% et afficher la fenêtre), si le D était un peu plus grand ou moins grignoté, ça fait un peu peur…
Par contre un exemple qui fait très peur, sur le même jeu de données, c'est le clone à 0,671% : on a du D, du J et un seul nucléotide dans le N.
Dans ce cas on pourrait passer à 60... mais cela ne fait que 5 de plus de cahque côté, on va toujours avoir des cas limite même à 60.
Mmmm…. on a déjà eu du mal à prendre cette décision 50 (n’oublions pas que c’est 40 en ce moment). Par contre, on pourrait imaginer un process qui met un warning sur certains clones. En sortie du FineSegmenter, on devrait savoir si on est dans un cas limite ou non.
Et ce problème est (dans certains cas) indépendant de la taille de la fenêtre : Si on a un V/J collé avec 0 zone de N, ce sera très limite même avec une fenêtre de taille 100 :-) On doit mettre un gros warning dessus, et permettre de revenir sur les reads.
N'oublions pas que c'est 60 en IGH pour l'instant… (4^5 = 1024).
Ce sont des cas que j'ai vus sans trop chercher, parmi les 100 clones du jeu de données que j'avais en face de moi. C'est ça qui fait peur. Évidemment il y aura toujours des cas limites, mais là je n'ai pas épluché tous nos résultats avec de l'IGH pour tomber sur LE cas limite.
Exemple 0481 mis dans notable.
Pour cet exemple, on est finalement sauvé (euh ? une délétion au troisième nucl de J) par ce que voit IMGT. Mais cela n'enlève pas le problème, on doit alerter si faible spécificité de la fenêtre (tâche dédiée). Être à 60 permet d'avoir 4^5... si on récupère bien du N sur un des côtés, ce qui est loin d'être sûr.
Maintenant, reste la question du -w par défaut. Les utilisateurs en multi doivent avoir la même qualité que ceux en IGH seul, et la qualité doit être au top pour tout le monde. On teste le -w 50 depuis longtemps en multi... et... les tests passent.
Revu une trentaine de clones des utilisateurs IGH (Florian, Eva, Jack). Aucun soucis pour le -w 50. Mais plusieurs soucis pour certaines spécificités avec zéro N qu'un -w 60 ne résoud pas.
Tranché, c'est douloureux. Je maintiens "The default value (=-w 50=) was selected to ensure a high-quality clone gathering."
Mise en prod server : si on hésite (non, il ne faut pas...), on pourra mettre -w 60 pour la config IGH. Tâche renommé, le pb est IGH.
La nouvelle tâche S22 m'a fait encore plus peur... mais on est bien sur autre chose que les discussions 50/60.
(sur rbx, IGH est encore en -w 60, tout le reste en -w 50 par défaut, sauf les configs [old])