cellranger count errors out as dm6 is passed to -transcriptome

[katsikora]

cellranger count --create-bam true --fastqs /RNA-Seqsinglecell_drosophila/fastq/MJ_02_250502_scRNAseq_D3_Lp_st5_Lp2 --id MJ_02_250502_scRNAseq_D3_Lp_st5_Lp2 --jobmode local --localcores 80 --localmem 400 --disable-ui --nopreflight --maxjobs 30 --transcriptome dm6 --sample MJ_02_250502_scRNAseq_D3_Lp_st5_Lp2
error: invalid value 'dm6' for '--transcriptome ': No such file or directory

[katsikora]

maxplanck-ie/10X_snakepipe#18

[katsikora]

same for GRCh38...

[WardDeb]

I think this is also due to #103 / #104, there is an additional mapping from a 'sanitized' organism name to the reference within the 10x_snakepipe repo. Perhaps these could also be stored within the organism on parkour @adRn-s ?

[adRn-s]

On Parkour we already have 3 'flavours' (name, label, yaml). Can't we accomodate our tools to these? First one is the most accurate string, like for e-mails and reports. But it has parenthesis and is not good for naming directories. The second one is for that matter, while the third is for snakePipes (so it may be a path, like this example: M. musculus (GRCm39) m39 /data/repository/organisms/GRCm39_ensembl_106/snakePipes_organism.yaml) ... Oddly enough, for drosophila the yaml entry for snakepipes is "dm6" (doesn't look like a path) but that shouldn't be the one we use to begin with... instead it should be "drosophila" (label).

We could add a 4th, like "fly" but it would be best to keep these under certain control. We already have 3 and it's difficult enough to keep track of which is used when. That's why I'd be more inclined to find cohesion than keep extending this dictionary.

[adRn-s]

isn't it a matter of adjusting these entries to match what we wrote on Parkour database?

https://github.com/maxplanck-ie/10X_snakepipe/blob/766d4904ea819af3d8c33e92b88da0547149f4ab/10x_scRNA/10x_scRNA.config.yaml#L10

[WardDeb]

isn't it a matter of adjusting these entries to match what we wrote on Parkour database?

https://github.com/maxplanck-ie/10X_snakepipe/blob/766d4904ea819af3d8c33e92b88da0547149f4ab/10x_scRNA/10x_scRNA.config.yaml#L10

Yea, but for me that's adding a 'fourth flavour', but stored outside of parkour and thus defeating the purpose of centralizing this.
Alternatively one could retain this information in the organism yaml, though this is snakePipes specific and thus also doesn't really belong there..

I'm also not sure. Any additional input more then welcome..

[katsikora]

Thanks for providing your points of view.
Do I understand correctly that, if we made the organism genome version strings equal between Parkour, snakePipes and 10x, then the problem would be solved? How about running a poll on this in an upcoming bioinfo-core meeting e.g. Thursday next week?

[adRn-s]

Just as part of the brainstorming, Parkour could also hold the path to the directory where cellranger reference genome is located (e.g. /data/repository/misc/cellranger_references/cellranger/refdata-gex-GRCh38-2020-A) which is analogous to what we've already been doing for snakePipes analysis launched via BRB. (Although in some cases snakePipes itself supports getting a name instead of a file path...)

Yeah, we could discuss this during the bioinfo-core meeting. I am inclined into dropping the usage of hardcoded strings and YAML files and instead have these centralized into Parkour for BRB to pick-up the needed location of reference genomes. This way, the end user picks a reference using the first string ('name') when loading the sequencing request, and then gets an analysis matching accordingly... BRB is in charge of using the corresponding tools (snakePipes, cellranger, etc.) and reference files...

[WardDeb]

Just as part of the brainstorming, Parkour could also hold the path to the directory where cellranger reference genome is located (e.g. /data/repository/misc/cellranger_references/cellranger/refdata-gex-GRCh38-2020-A) which is analogous to what we've already been doing for snakePipes analysis launched via BRB. (Although in some cases snakePipes itself supports getting a name instead of a file path...)

This is what I originally had in mind, and would be the cleanest solution imo..
The alternative (having everything in parkour rather then hardcoded yaml / strings) I like even more, though might be quite cumbersome to implement on the parkour level ?

[adRn-s]

Oh, I misunderstood the intention, and was reluctant to add a column to write "fly" when we already had all the other 'flavours'. We can always add new columns to any database table and fill them in. It does take some "effort" because of the many steps, having a backup before and after the change. Plus, we've working on a major refactoring for the last couple of months (changing libraries and samples tables, among others) but since these are mostly independent it could be done.

What could also be a pain, is that starting from there on, Parkour would return 4 strings (or a None as 4th element) instead of 3. So, the downstream code in BRB could need adjustments... not that I foresee any, we were working with a dictionary of strings, so it should be fine.