KeyError in sqanti_qc2.py version 3.5 about sqanti2

[Magdoll]

Hi @defendant602 ,

I've fixed a few ORF related bugs in the last versions. If the issue still exists for the latest v3.8, please let me know and can you share the input file with me in private?

--Liz

[defendant602]

Hi Liz,

I have downloaded the version 3.8 and test it on my dataset which failed in version 3.5. Sorry I have to tell you the problem remains the same as KeyError in line 1278 of sqanti_qc2.py.

However, when I test other three datasets with version 3.8, all of them completed without an error. So this KeyError may be because of something I don't know in this particular input dataset.

Sorry I can't figure out a convenient way to share my input data with you, since filesize of the genome.fa is actually quite big (2Gb).

[Magdoll]

Hi @defendant602 ,

Interesting it may be an edge-case bug.

It is possible for you to share large files with me if you give me your email address. I will request a confidential upload.

--Liz

[defendant602]

Thanks for the efforts you've made to make this software more perfect. This is my email address [email protected] and I will share my input dataset with you.

Thanks again.

[Magdoll]

@defendant602 ,

Thank you. Request for file upload sent to your email.

--Liz

[Magdoll]

Hi @defendant602 ,

The issue came from the SQANTI2 default run of minimap2 had multiple mappings for a query PB.24244.8, and none of them aligned the query entirely, causing issue with mapping the predicted ORFs back to the genomic location. You can tell by looking for PB.24244.8 in the file all.collapsed.rep.renamed_corrected.sam.

One solution is to provide the input as a GTF with the --gtf option. This skips the minimap2 run and ensures you have the full mapping (supposedly) for whatever aligner + parameter you used originally.

-Liz

[Magdoll]

Closing unless otherwise noted.