Bonjour,
Je suis en train de tester Galaxy pour une formation que je donne la semaine prochaine (UseGalaxy.fr TIaaS rarebip2 Status).
Je voulais m'assurer que STARsolo fonctionnait pour le mapping de reads de données single cell (300 cellules). Normalement c'est quelque chose qui tourne très rapidement sur le serveur Galaxy IFB (quelques minutes). Là le job tourne depuis pas mal de temps (~20'). Je me demandais du coup si il y avait bien les ressources suffisantes alloué à STARsolo.
Je vous remercie
Job Information
Galaxy Tool ID toolshed.g2.bx.psu.edu/repos/iuc/rna_starsolo/rna_starsolo/2.7.11a+galaxy0
Job API ID fad5f80c8e8544c6
Je confirme qu'il y a un problème vu le temps nécessaire pour mapper les reads de 300 cellules. Pas d'erreur néanmoins pour l'instant.
Bonjour @puthier
L’outil STARsolo est exécuté avec 4 cœurs et 40 Go de RAM.
Pouvez-vous me dire quels paramètres vous avez choisis pour l’exécution sur le cluster?
Thomas
Bonjour Thomas,
Je te passe les paramètres. Cependant, pour le test, j'ai juste relancé un job dans un de mes historiques qui normalement tourne en 5'. Il est toujours en train de tourner. De mon côté, je vais essayer de relancer en rechargant les jeux de données dans galaxy.
Denis
Tool Parameters
| Input Parameter |
Value |
| Custom or built-in reference genome |
indexed |
| Reference genome with annotation |
without-gtf-with-gtf |
| Select reference genome |
hg19 |
| Gene model (gff3,gtf) file for splice junctions |
5: Homo_sapiens.GRCh37.75.gtf |
| Elements to use from the gene model to use for splice junctions |
exon |
| Length of the genomic sequence around annotated junctions |
100 |
| Type of single-cell RNA-seq |
CB_UMI_Simple |
| Input Type |
repeat |
| RNA-Seq FASTQ/FASTA file, Barcode reads |
1: subset_pbmc_1k_v3_S1_L001_R1_001.fastq.gz |
3: subset_pbmc_1k_v3_S1_L002_R1_001.fastq.gz|
|RNA-Seq FASTQ/FASTA file, cDNA reads|2: subset_pbmc_1k_v3_S1_L001_R2_001.fastq.gz
4: subset_pbmc_1k_v3_S1_L002_R2_001.fastq.gz|
|RNA-Seq Cell Barcode Whitelist|6: 3M-february-2018.txt.gz|
|Configure Chemistry Options|Cv3|
|Barcode Size is same size of the Read|true|
|UMI deduplication (collapsing) algorithm|1MM_CR|
|Type of UMI filtering|Remove UMIs with N and homopolymers (similar to CellRanger 2.2.0)|
|Matching the Cell Barcodes to the WhiteList|Multiple matches (CellRanger 2, 1MM_multi)|
|solo||
|Strandedness of Library|Read strand same as the original RNA molecule|
|Collect UMI counts for these genomic features|Gene: Count reads matching the Gene Transcript|
|Cell filtering type and parameters|no_filter|
|output_raw|true|
|Field 3 in the Genes output.|Gene Expression|
|Read alignment tags to include in the BAM output|NH (number of reported alignments/hits for the read) HI (query hit index) AS (local alignment score) nM (number of mismatches per (paired) alignment)|
|Output global gene count|false|
|Output unmapped reads in the BAM|false|
|MAPQ value for unique mappers|60|
|junction_limits||
|Maximum number of junctions for one read (including all multimappers)|1000|
|Maximum number of collapsed junctions|1000000|
|Maximum number of inserts to be inserted into the genome on the fly.|1000000|
|Compute coverage|None|
|outWigStrand|false|
L'url de l'historique si ça peut aiguiller.
Est ce que tu as la ligne de commande que tu as utilisé lors de la soumission sur le cluster de l'IFB ?
Dans l'information sur le job, pour l'attribut "command line:" il y a marqué "empty".
J'ai rechargé le jeu de données dans un nouvel historique. j'ai relancé et là j'ai une nouvelle erreur qui me dit: "
Detected Common Potential Problems
The tool was started with one or more duplicate input datasets. This frequently results in tool errors due to problematic input choices.
J'ai vérifié plusieurs fois les paramètres... Du coup là j'ai chargé les input sur usegalaxy.org pour voir si j'ai aussi le problème là bas. Je te tiens au courant.
J'ai réussi à faire tourner StarSolo sur usegalaxy.org. Ca semble indiquer qu'il y aurait peut être un problème sur le cluster de l'IFB pour cet outil (?).
Le jeu de données et le résultat StarSolo sont sur usegalaxy.org:
Galaxy
Est-il possible d'importer cet historique sur galaxy France pour tester de votre côté ?
denis
Sur .org , ils ont mis 10 cores au lieu de 4, je viens de lancer un test sur .fr
Ca a marché de ton côté ? Normalement, c'est très rapide ?
Non ça a mis presque 5h ...
Je regarde ça en fin d'aprem ou demain
Salut Thomas, as tu trouvé une solution ?
Je te remercie.
Denis
Salut @puthier
Après creusage, ça peut venir du génome de référence utilisé ?
avec hg19 le job dure plusieurs heures.
avec hg19chrX le job dure 20-40 min.
Thomas
Oui parce que hg19chrX c'est juste le chromosome X du hg19 (vs tou le génome). C'est une formation que j'ai déjà donnée au moins 4-5 fois sur le cluster de l'IFB et normalement c'est très rapide. Ce qui est totalement anormal c'est que, avec le génome complet, ça prenne quelques minutes sur usegalaxy.org et plusieurs heures sur usegalaxy.fr (le jeu de données est celui utilisé par le GTN dans ce tuto: Hands-on: Pre-processing of 10X Single-Cell RNA Datasets / Pre-processing of 10X Single-Cell RNA Datasets / Single Cell). Le nombre de processeurs utilisé ne permet pas d'expliquer la différence. Avec plusieurs heures ça devient incompatible avec une formation (idem pour hg19chrX en 20-40 min). Est-ce qu'il n'y aurait pas une histoire de machine qui swap ? Ou sinon, est-ce que l'index STAR a bien été produit avec la même version de STAR ? Est-ce que tu as pu le lancer en ligne de commande ?
Pour information un alignement avec STAR ça nécessite 30-40Go. Le problème pourrait aussi venir de là (?)
Ca n'a pas l'air d'être l'index car si on fourni le Chr19 dont l'indexage est relativement rapide ça reste très long. Je pencherais pour un problème mémoire, comme un soft qui est long quand ça swap, mais je ne me rends pas bien compte de comment cela tourne en interne.