Closed CIWa closed 4 years ago
That looks like a serious bug. I tried to reproduce that here but could not. That should not happen, the reference set of transcripts is loaded and clustered only once and it should not change across processing of multiple query files.
It's that bad and unexpected that I am beginning to suspect some sort of data corruption going on there. Running the program through sanitizers does not seem to reveal anything low level on my system with my data files. However perhaps there is a bug somehow triggered by specific input like the one you had there. Is it possible to share those 3 files with me? (annotation_file.gff + the 2 query files)
Btw v0.11.6 introduced an unnecessarily stringent calculation of transcript (and locus) level accuracy (along with some possibly buggy counts there). I just released v0.11.7 correcting that (and reversing to the same calculation used before v0.11.6). Unfortunately that has nothing to do with the buggy behavior reported here (tested both v0.11.6 and v0.11.7 and could not reproduce this strange behavior with either).
Yes, no problem, please find the link to the related data in your gmail-inbox. Thanks also for the info about the update, I will make sure to use this version in the future then. I tested it already on the data set reported here, but, as you expected, it did not change anything about the bug.
Thank you for the quick help! Best wishes, Isabel
Thank you for the data. It seems the issue is caused by the somewhat unusual situation (that I did not take into account) where each of the query files have a different set of reference sequences (scaffolds/contigs: 4607 for the scallop assembies, 4286 for the stringtie assemblies) and neither of them match the set of reference sequence in the annotation GFF, which is larger (5816).
The reference transcripts are not counted for the reference sequences (scaffolds) having no entries at all in a query transcript data set. I'm working on a fix for this.
Apologies for the long delay in responding here -- I had fixed this a while ago, the fix is included in the v0.12.1 release
All right, thanks a lot!
Best wishes, Isabel
Hi,
Thank you very much for providing this handy tool! I used gffcompare to compare a merged assembly by scallop (v 0.10.5) + TACO (v 0.7.3), and one assembled and merged by Stringtie (v 2.1.4). I then realised that gffcompare seems to loose several reference mRNAs between the analysed assemblies. Furthermore, the numbers of lost mRNAs are inconsistent across variation in the order that the assemblies are called. I was just wondering if this is intended, or a bug?
Best wishes, Isabel
Scallop-assembly called first:
Stringtie-assembly called first: