vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-07-18T09:58:40+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3389Séquences stockées dans `seqs_by_window` : champs, compression ?2018-07-18T09:58:40+02:00Mathieu GiraudSéquences stockées dans `seqs_by_window` : champs, compression ?Une réflexion parallèle à #2120/#3387 : l'espace mémoire au cours de la phase 1 provient quasi totalement de
`map<junction, BinReadStorage > seqs_by_window`. Vu ce qu'il y a dans le `BinReadStorage`, il est probable que cela soit dominé ...Une réflexion parallèle à #2120/#3387 : l'espace mémoire au cours de la phase 1 provient quasi totalement de
`map<junction, BinReadStorage > seqs_by_window`. Vu ce qu'il y a dans le `BinReadStorage`, il est probable que cela soit dominé par les `list<Sequence> *bins`. Dans une `Sequence`, il y a :
```
typedef struct read_t
{
string label_full;
string label;
string sequence; // Sequence: original string representation
string quality;
int* seq; // Sequence: seq representation
size_t marked_pos; // Some marked position in the sequence
} Sequence;
```
Est-ce que tout cela est vraiment conservé et utile ?
- La `quality` double la taille (mais elle est utile pour la representative, c'est cela ?)
- `label_full` et `label` pourraient être supprimés (mais bon, quasi-négligeable ?), sauf quand on veut `-a` ou `-u`
- Est-ce que cela aurait un intérêt de stocker `sequence` et `quality` de manière compressée ?
cc @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3386Indexer séparément, mais à la suite, les up/down-stream2018-07-16T07:31:14+02:00Mathieu GiraudIndexer séparément, mais à la suite, les up/down-streamNous aimons le up/down-stream. Nous avons fait #3008 pour J+down, et, précédemment, la même chose Dd2/Dd3.
Mais idéalement, on devrait distinguer des situations comme `JJJJJdddd`, `JJJJJCCCCC`, `JJJJJ----`. Et, avec des reads non-longu...Nous aimons le up/down-stream. Nous avons fait #3008 pour J+down, et, précédemment, la même chose Dd2/Dd3.
Mais idéalement, on devrait distinguer des situations comme `JJJJJdddd`, `JJJJJCCCCC`, `JJJJJ----`. Et, avec des reads non-longues, `JJJJJdddddCCCC` ne devrait pas arriver.
Certes, avoir d'un côté `J.fa` et de l'autre `J+down.fa` fournit une solution, idem pour Dd2/Dd3, couplé avec des entrées dans `germline.h` différentes (et des méthodes de segmentation différentes), mais on sent la recopie d'informations. Et même en situation "normale" `JJJJJdddd`, on aimerait #3147, mais là cela relève plutôt du FineSegmenter.
Serait-ce possible d'avoir un mécanisme où l'on indexe directement `(J + down)`, avec un kmer `down` déclenché
dès le premier nucléotide de `down` ? Avec Aho, c'est peut-être encore plus simple à implémenter ?
Cela demanderait aussi d'adapter les méthodes de segmentation... ou possiblement #3377.
Ping #2138.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3379identito-vigilance: protocole par le biais des SNP2018-07-13T16:21:52+02:00Thonier Florianidentito-vigilance: protocole par le biais des SNPIl s'agit d'une piste de réflexion sur ce que j'ai entendu cette semaine au labo.
Dnas le cadre des manips de séquençage de l'équipe de Rennes en oncologie ou somatique, ils passent des échantillons pour voir des SNP.
L'association d...Il s'agit d'une piste de réflexion sur ce que j'ai entendu cette semaine au labo.
Dnas le cadre des manips de séquençage de l'équipe de Rennes en oncologie ou somatique, ils passent des échantillons pour voir des SNP.
L'association de quelques SNP permet de discriminer des patients et par exemple de savoir le sexe, et aussi un code de quelques lettres qui pourra devenir unique.
Ces SNP sont répartits sur de nombreux gènes qui sont justement ceux qu'ils observent. Ils n'en ont que quelques un de dispo pour cette raison (8 ou 9). Ça ne fait pas forcement un très grande combinatoire, mais ils l'utilisent à l'échelle d'un run uniquement.
Vu le type de données que l'on a, ce n'est pas envisageable (mutation, recombo, locus différents suivant les samples,...). Mais c'est à garder dans un coin de notre esprit.
PS; ça fait prendre conscience qu'il en faut peu pour identifier quelque un.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3370Une séquence passe en unexpected au lieu d'IGH2018-07-13T16:08:46+02:00Mikaël SalsonUne séquence passe en unexpected au lieu d'IGHCe n'est pas extrêmement choquant vue la séquence.
Il s'agit de la séquence `#1347 vh2` de `gosh-igh.should-vdj.fa`. Elle contient un réarrangement VDJ normal mais à la fin elle a aussi du V dans le sens négatif.
Auparavant la séquence...Ce n'est pas extrêmement choquant vue la séquence.
Il s'agit de la séquence `#1347 vh2` de `gosh-igh.should-vdj.fa`. Elle contient un réarrangement VDJ normal mais à la fin elle a aussi du V dans le sens négatif.
Auparavant la séquence était vue comme une séquence VDJ normale mais avec la mise à jour des germlines, on a plus de k-mers reconnus comme V- à la fin de la séquence ce qui donne une meilleure e-valeur à la recombinaison inattendue par rapport à la VDJ classique.
Voici les affectations :
```
_ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _
_ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H _ _+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _+h _ _ _ _ _ _+h+h+h
+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
```
Est-on choqué que ce soit unexpected ou non ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3360Gestion plus propre des warnings2021-02-03T09:09:32+01:00Mikaël SalsonGestion plus propre des warningsPour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un...Pour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un warning dans le JSON se fait par un code unique, sous forme de chaîne, suivie d'une description.
Plusieurs éléments :
* [ ] Ne pourrait-on pas avoir une constante pour chaque warning (toujours préférable aux chaînes pour lesquelles on risque une typo) ?
* [ ] Le message ne peut-il pas être mis automatiquement (tous définis dans un tableau commun) plutôt que d'avoir à le réécrire à chaque fois ?
* [x] Les warnings ne peuvent-ils pas exister indépendamment du JSON ? Ensuite c'est chaque type de sortie qui définit ce qu'elle fait du warning.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3338100% d'alignements sont récupérés lors de certaines exécutions2018-07-06T11:10:44+02:00Cyprien Borée100% d'alignements sont récupérés lors de certaines exécutions(observé sur #3259)
Sur certaines commandes, le taux de séquences aligné est de 100% malgré l'utilisation du filtrage.
Quelques commandes pour s'en rendre compte :
* `./vidjil-algo -c segment -g germline/homo-sapiens.g -2 -3 -X 100 ...(observé sur #3259)
Sur certaines commandes, le taux de séquences aligné est de 100% malgré l'utilisation du filtrage.
Quelques commandes pour s'en rendre compte :
* `./vidjil-algo -c segment -g germline/homo-sapiens.g -2 -3 -X 100 -Z 1 demo/LIL-L4.fastq.gz` (**IGH** et **TRD+** à 100%)
* `./vidjil-algo -c segment -g germline/homo-sapiens.g -x 100 -Z 5 demo/LIL-L4.fastq.gz` (**IGH** et **IGK+** à 100%)https://gitlab.inria.fr/vidjil/vidjil/-/issues/3304Calcul de la séquence consensus : changer le choix des reads utilisés2020-12-11T13:15:02+01:00Mikaël SalsonCalcul de la séquence consensus : changer le choix des reads utilisésPour des questions d'optimisation tous les reads ne sont pas stockés et nous n'utilisons qu'un échantillon des reads d'un clone (pour les gros clones) afin de calculer le consensus. Ce choix est géré dans la classe `ReadQualityScore` du ...Pour des questions d'optimisation tous les reads ne sont pas stockés et nous n'utilisons qu'un échantillon des reads d'un clone (pour les gros clones) afin de calculer le consensus. Ce choix est géré dans la classe `ReadQualityScore` du fichier `read_score.cpp` : on se base à la fois sur le dernier percentile de la qualité du read et sur la longueur du read. Les reads les plus longs et de meilleure qualité sont donc choisis.
On va donc biaiser le choix en faveur des séquences les plus longues. Ce qui est à la fois souhaitable : pour des raisons de qualité de séquençage on pourrait se retrouver avec uniquement une faible portion des reads du clone qui sont de pleine longueur (si on a beaucoup d'erreurs sur R2 le merge va échouer par exemple). Et c'est à la fois non souhaitable car on va privilégier les séquences les plus longues qui ne sont pas forcément représentatives du clone (cf. #3290).
Une solution serait de se contenter d'un échantillon aléatoire des reads de meilleure qualité (ce qui est plus représentatif du clone). Cela pose la question de comment constituer cet échantillon aléatoire au fur et à mesure sans connaitre a priori la taille du clone et sans biaiser en faveur des premiers ou des derniers reads.
Si cette solution donne une séquence consensus dont la longueur n'est pas satisfaisante on peut ensuite passer à une autre stratégie privilégiant les longueurs les plus élevées.
Mais je n'arrive pas à voir une solution unique qui donnerait le résultat attendu dans tous les cas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3301Allèles non *01 (non-génome de référence) et up-downstream2018-07-20T15:38:51+02:00Mathieu GiraudAllèles non *01 (non-génome de référence) et up-downstreamSpécialisation de #3009 pour les allèles `*02` et autres
@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/148#note_99385:
> En fait on ne sait pas récupérer la séquence aval de IGHJ6*02 car c'est un allèle
Décide-t-on...Spécialisation de #3009 pour les allèles `*02` et autres
@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/148#note_99385:
> En fait on ne sait pas récupérer la séquence aval de IGHJ6*02 car c'est un allèle
Décide-t-on de
- prendre la même séquence aval que le génome (et que `*01`) ? Pourquoi pas, mais... il peut y avoir aussi des mutations dans les séquences aval, non connues dans le génome de référence et cachées ailleurs
- ne pas prendre de séquence aval pour `*02` ? Cela crée une dissymétrie, mais, d'un autre côté, si on a beaucoup d'aval qui colle parfaitement avec `*01`, c'est difficile de dire qu'on devrait coller à `*02` ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3300Ordre sur les flags de task.py2018-06-18T18:02:51+02:00Mathieu GiraudOrdre sur les flags de task.pyUne pensée après #3289 / !209 : on aurait pu avoir des flags avec des opérations d'ordre (comme ce qu'on met dans le mail) :
NO_JOB → QUEUED → ASSIGNED → RUNNING → COMPLETED
Mais bon, c'est sûrement inutilement compliqué.Une pensée après #3289 / !209 : on aurait pu avoir des flags avec des opérations d'ordre (comme ce qu'on met dans le mail) :
NO_JOB → QUEUED → ASSIGNED → RUNNING → COMPLETED
Mais bon, c'est sûrement inutilement compliqué.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3297Faire des cas difficiles pour les heuristiques (segmentation, filtrage) par g...2018-07-11T18:22:34+02:00Mathieu GiraudFaire des cas difficiles pour les heuristiques (segmentation, filtrage) par grainesPour #3183, #3223, #3225, ce serait bien de faire des séquences (même artificielles) qui mettraient l'heuristique de filtrage en difficulté... de la même manière qu'on a déjà beaucoup de tests sur des cas limites pour ~"cpp\-heuristic" ....Pour #3183, #3223, #3225, ce serait bien de faire des séquences (même artificielles) qui mettraient l'heuristique de filtrage en difficulté... de la même manière qu'on a déjà beaucoup de tests sur des cas limites pour ~"cpp\-heuristic" .
Cela dépend aussi fortement des graines choisies. #1364https://gitlab.inria.fr/vidjil/vidjil/-/issues/3281Fichiers BAM avec données pairées : exception ou non ?2018-06-13T09:25:11+02:00Mikaël SalsonFichiers BAM avec données pairées : exception ou non ?Lorsque le BAM avait été implanté, il avait été prévu de ne pas permettre l'utilisation de données pairées (car les reads ne sont pas fusionnés), comme indiqué dans la doc. Une exception est donc levée dans un tel cas. Il existe un seul ...Lorsque le BAM avait été implanté, il avait été prévu de ne pas permettre l'utilisation de données pairées (car les reads ne sont pas fusionnés), comme indiqué dans la doc. Une exception est donc levée dans un tel cas. Il existe un seul cas où on devrait permettre cela : du RNA-Seq car fusionner les reads ne présente aucun intérêt.
Or le seul cas de BAM uploadé sur le serveur public c'est du RNA-Seq pairé ! (#3263)
On peut très bien rester sur une exception (avec un message plus explicite car là c'est uniquement une assertion qui échoue) et dire qu'on ne gère que les FASTQ. Aucune garantie sur le reste.
Une alternative serait de mettre un warning (#2247). Le problème c'est qu'une personne envoyant un fichier BAM avec des données pairées d'amplicons verra ses données analysées juste avec un warning et serait probablement assez peu motivée pour réuploader 2 FASTQ et relancer l'analyse alors qu'elle a déjà des résultats devant les yeux.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3269vidjil.cpp ne devrait pas, par défaut, sortir un fichier par clone segmenté2018-06-22T12:04:52+02:00Mathieu Giraudvidjil.cpp ne devrait pas, par défaut, sortir un fichier par clone segmentéUn *fichier* `ofstream out_clone(clone_file_name.c_str())` est ouvert par clone sous le `-z`. Il faudrait voir si on souhaite garder ce fonctionnement, ou bien limiter cette sortie à quelques clones.
Non essentiel pour l'instant (c'est...Un *fichier* `ofstream out_clone(clone_file_name.c_str())` est ouvert par clone sous le `-z`. Il faudrait voir si on souhaite garder ce fonctionnement, ou bien limiter cette sortie à quelques clones.
Non essentiel pour l'instant (c'est ce qu'on a toujours fait, et le temps n'est pas si grand), mais devra être résolu avant qu'on fasse en routine des `-z 10000`.
cc @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3267Filtrage des germlines : le désactiver pour les "petites" germlines ?2018-07-06T11:10:44+02:00Mathieu GiraudFiltrage des germlines : le désactiver pour les "petites" germlines ?Faudrait-il quelque chose pour désactiver le filtrage sur certaines germlines ?
- Un truc en dur qui le ferait que pour les `IGHV` (et éventuellement d'autres pour lesquels on voit une accélération) ? Cela peut être largement suffisa...Faudrait-il quelque chose pour désactiver le filtrage sur certaines germlines ?
- Un truc en dur qui le ferait que pour les `IGHV` (et éventuellement d'autres pour lesquels on voit une accélération) ? Cela peut être largement suffisant dans un premier temps.
- Ou bien plus un truc plus fin, automatique avec la taille de la germline ?
(quand c'est désactivé, pas de construction de l'automate comme dans #3268).
cc @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3225Filtrage par automate : prendre les N meilleures séquences et leurs « voisines »2018-10-10T15:37:05+02:00Mikaël SalsonFiltrage par automate : prendre les N meilleures séquences et leurs « voisines »En général je pense que #3217 avec N = 1 donnera de bons résultats (en gérant les ex-aequo). Mais on aura probablement des situations où la vraie séquence est en fait en 2è ou 3è position mais juste avec quelqes k-mers de moins.
On pour...En général je pense que #3217 avec N = 1 donnera de bons résultats (en gérant les ex-aequo). Mais on aura probablement des situations où la vraie séquence est en fait en 2è ou 3è position mais juste avec quelqes k-mers de moins.
On pourrait dire qu'on prend N = 5 pour prendre une marge de sécurité pour ces cas-là. Mais c'est dommage de prendre 5 gènes dans le cas où le premier est largement devant en termes de nombres de k-mers trouvés.
On pourrait plutôt se dire qu'on prend les N meilleures séquences et leurs voisines proches en termes de nombres de k-mers trouvés, si elles existent. Toute la question est comment définir que le nombre d'occurrences est suffisamment proche ?
S'il est à 0, on a un ex aequo et on considère déjà qu'on doit le prendre.
Si on a 1 k-mer de moins, on sent bien que ce n'est pas très significatif et qu'on devrait prendre ce gène en considération aussi.
Si on a une erreur de séquençage qui nous éloigne du vrai gène et qui nous rapproche, à tort, d'un autre gène, cela peut nous faire perdre k k-mers.
Mais la distance permise dépend aussi de la longueur du gène : il est normal de tolérer une distance plus grande pour des gènes plus grands.
Faut-il avoir des calculs de probabilités ?Algo 2018.09https://gitlab.inria.fr/vidjil/vidjil/-/issues/3222vue commune pour les preprocess de merge2023-06-22T17:18:32+02:00Thonier Florianvue commune pour les preprocess de mergeUne question me vient en analysant #3219 : Laisse-t-on à terme le choix du software de merge ou l'impose-t-on ?
Si on laisse le choix; propose-t-on de conserver les reads non assemblés pour rejouer le merge avec un autre soft (ou même ...Une question me vient en analysant #3219 : Laisse-t-on à terme le choix du software de merge ou l'impose-t-on ?
Si on laisse le choix; propose-t-on de conserver les reads non assemblés pour rejouer le merge avec un autre soft (ou même simplement d'autres paramètres) ?
De plus, propose-t-on une vue unifiée entre les diverses sorties (cf revient à faire un json des log de preprocess ). On pourrait par exemple pour les merge indiquer des tableaux des percentiles sur la longueurs des reads assemblés par exemple; Cette étape serait supplémentaire au software.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3219Fusion de reads : essayer Flash (et BBMerge ?)2020-03-20T12:51:41+01:00Mikaël SalsonFusion de reads : essayer Flash (et BBMerge ?)Dans la publi d'OAS (cf. vdj#677) ils disent utiliser FLASH pour fusionner les reads :
* Site d'origine : https://ccb.jhu.edu/software/FLASH/
* Github : https://github.com/dstreett/FLASH2
L'avantage c'est que c'est open source.
Un arti...Dans la publi d'OAS (cf. vdj#677) ils disent utiliser FLASH pour fusionner les reads :
* Site d'origine : https://ccb.jhu.edu/software/FLASH/
* Github : https://github.com/dstreett/FLASH2
L'avantage c'est que c'est open source.
Un article compare plusieurs logiciels de fusion (dont le leur, BBMerge, qui est évidemment le meilleur) : http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0185056
Flash semble faire moins d'erreur que PEAR et être plus rapide. Flash est aussi plus rapide que BBMerge sur 1 thread. Mais il semble moins correct que BBMerge (d'après leur évaluation…). C'est Flash 1 qui est testé et non Flash 2. BBMerge ne semble pas être distribué seul mais au sein d'un package regroupant d'autres logiciels ce qui risque de rendre la distribution moins pratique.Thonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3218Supprimer les k-mers non significatifs ?2020-02-21T21:19:30+01:00Mathieu GiraudSupprimer les k-mers non significatifs ?(Juste une réflexion peut-être non pertinente, à voir uniquement si le temps du filtrage reste significatif après #3217.)
Sur IGHV (347 gènes), en prenant des k-mers de taille 5:
- 1031 k-mers différents, dont
- 36 k-mers qui appar...(Juste une réflexion peut-être non pertinente, à voir uniquement si le temps du filtrage reste significatif après #3217.)
Sur IGHV (347 gènes), en prenant des k-mers de taille 5:
- 1031 k-mers différents, dont
- 36 k-mers qui apparaissent dans >= 300 des gènes.
- environ 500 k-mers qui apparaissent dans >= 50 des gènes
Cela fait beaucoup de k-mers qui apparaissent très souvent (et qui vont "charger" l'automate, le match ne serait-il pas en `O(zn)`, où `z` est le nombre moyen d'affectations par k-mer) ?
On verra quand on aura le temps exact du filtrage (sans suppression) pour #3190 et après #3217, mais est-ce que ces 36 kmers apparaissant trop souvent apportent vraiment du signal dans le filtrage ? (Ils peuvent certes amener un signal négatif, on pourrait à la limite stocker cette info.)
cc @mikael\-s @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3216Utilisation des séquences "cibles"2023-06-28T16:58:04+02:00Thonier FlorianUtilisation des séquences "cibles"Problème de Patrick :
> comparer le nombre de read d’un patient (pour une cible) à la moyenne des reads de cette cible sur l’ensemble des patients (ou sur une cohorte définie, par exemple 200 patients de notre site). Ceci nous permettra...Problème de Patrick :
> comparer le nombre de read d’un patient (pour une cible) à la moyenne des reads de cette cible sur l’ensemble des patients (ou sur une cohorte définie, par exemple 200 patients de notre site). Ceci nous permettra d’avoir des critères d’acceptation du run.
Pour ce faire, il faut faire une recherche de cette cible sur l’ensemble des samples sélectionnées:
* Premier point : il faut déjà pouvoir spécifier la cible.
* Pouvons-nous nous contenter de le faire sur la liste des clones disponible dans les fichiers vidjil ? Nous pourrions alors passer à côté d'une séquence qui ne correspond pas à un clone du top 100, mais qui pourrait avoir son intérêt quand même.
* Rechercher sur le fichier source de séquençage ? Certainement plus long d'un point de vue informatique, mais cela reste-t-il de l'ordre du raisonnable ?
* Faudra-t-il utiliser des séquences dégénérées ?
Autre solution: passer par cloneDB. Serait-ce plus simple d'un point de vue technique ? Cela permettrai-t-il la même granulométrie dans la recherche pour l'inclusion des divers échantillons ?
@Patrick : Aurais-tu un exemple de cible que tu cherches , les samples associés, et ce que tu as (ou t'attends) a retrouver stp ?
@magiraud @mikael\-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3187Filtrage du BioReader pour align_against_collection : gérer le cas s'il y a p...2018-07-12T18:00:22+02:00Mikaël SalsonFiltrage du BioReader pour align_against_collection : gérer le cas s'il y a peu de résultats à getMultiResults()On pourrait avoir le cas où on a peu de k-mers correspondent à des gènes V existants (à cause de mutations par exemple).
Si on a seulement 3 k-mers qui correspondent à du V4 et 2 à du V6, a-t-on vraiment envie de privilégier ces deux gè...On pourrait avoir le cas où on a peu de k-mers correspondent à des gènes V existants (à cause de mutations par exemple).
Si on a seulement 3 k-mers qui correspondent à du V4 et 2 à du V6, a-t-on vraiment envie de privilégier ces deux gènes-là plutôt que les autres ? Il y a donc un certain seuil à partir duquel on n'a plus envie de filtrer le `BioReader`.
On pourrait calculer un seuil de p-valeur pour savoir si le nombre de k-mers est satisfaisant par exemple. On a déjà tout ce qu'il faut normalement.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3181Lancer CloneDB depuis fuse.py ou en offline2019-02-14T18:19:54+01:00Mathieu GiraudLancer CloneDB depuis fuse.py ou en offlineExtrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #...Extrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #1744 (qui pourrait être fait séparément).
À voir aussi comment on indique que cela a été fait "à une certain moment" (et donc, si on revient plus tard, pas forcément à jour). Et/ou relancer périodiquement CloneDB sur le serveur ?