Open mcortes-lopez opened 1 year ago
Yeah, there's really no need for a nucleus-specific workflow for kb count; it makes sense to simply produce the three matrices (via what we currently call the lamanno workflow) and sum up the ambiguous and nascent (unspliced) matrices for nucleus data since we're indexing nascent+mature transcripts anyway.
First, I recommend installing the latest version of kallisto-D, the kb_python dlist branch, and the bustools dlist branch. Supply the bustools path to kb count via --bustools $bustools .
Second, kallisto-D cannot generate the c1 and c2 files (kb ref is responsible for doing all the fasta/gtf manipulation+extraction stuff).
At the time of the preprint, we were unable to create an RNA velocity workflow (because that required modifications to multiple different software, including both kb-python and bustools as well as one of kb-python's dependencies), therefore we only focused on generating a single count matrix which was enough to illustrate our point about accurately classifying what's "spliced", what's "unspliced", what's in-between, and how ambiguous things are allocated in cellular vs. nuclei workflows (by current convention using strong albeit bad assumptions) and how to filter out false positive mappings in all cases. I had wanted to create an RNA velocity workflow at that time but I had some personal issues (unfortunately, some rather serious medical issues) come up at the time.
Some time later, I finally completed the RNA velocity workflow (which, as you correctly point out and as alluded to in the preprint, involves indexing nascent transcripts in addition to cDNA).
Install the newest version of kb-python and do the following:
kb ref --kallisto=$kallisto --d-list=genome.fasta --workflow=lamanno -t 44 -i index.idx -g t2g.txt -c1 c1.txt -c2 c2.txt -f1 cdna.fa -f2 nascent.fa genome.fasta genome.gtf
Note that the --d-list option above is optional. It basically creates relevant distinguish k-mers across the entire genome to prevent random crap in intergenic regions from decreasing mapping specificity (not really necessary unless you're dealing with a species with crappy annotation and it will make "kb ref" take longer and will make mapping consume a couple gigabytes more memory).
Anyway, proceed to run kb count:
kb count --sum=cell --workflow=lamanno ...
You'll get a cells_x_genes.cell.mtx (these are your "spliced counts" -- the ambiguous counts are allocated into this matrix) and you'll get a cells_x_genes.2.mtx (these are your "unspliced counts"). You feed these two matrices into your RNA velocity workflow.
You can also use --loom and --h5ad to get those two matrices in those file formats.
P.S. We're still updating the preprint (the first version presented some good ideas but needs some serious polishing and few significant corrections).
P.P.S. For future issues, just use the main kallisto repo since I think we're going to migrate there soon for this new release (which should be coming in a matter of weeks if not days).
Hi, I am trying to do velocity analysis in nuclear data, implementing some of the ideas discussed in your paper. I followed some of the steps contained in the scripts from HSHMP_2022. Then I realized that to work with the kb count output in scVelo I would need to run the
lamanno
workflow (I read in some kallisto issue that the nuclei workflow is not advised, this after I tried it and no spliced/unspliced matrices were found in my loom object). However, something seems to fail during the quantification, as I get empty unspliced matrices. The spliced matrices seem to be fine.Here are the basic steps I follow:
I get a unspliced bus file, and the json inspect does not look so different from the spliced, however, the counts matrix that is contained in the loom object is empty. I suspect the issue is in the -c1 and -c2 files, because I do not think kallisto-D has an option to generate these files. Is there a way to obtain these files? Or would you recommend another strategy to be able to work with the kallisto-D quantifications in scVelo. Also, on these lines, would potentially kallisto-D be useful to mask regions in the genome that might alter the quantifications? Like regions that tend to be mis-primed?