Tophat 2.0.10 woes: Error running 'long_spanning_reads'

[nickschurch]

Hi

I know this error has been reported before for previous versions of Tophat2; well, its still happening in 2.0.10. As suggested by the tophat webpage, I've posted a report in the tuxedo-tools-users google group that has remained stubbornly unanswered and un-addressed.

Changing the number or cpus, amount of RAM or changing the --coverage-search/--no-coverage-search flags doesn't seem to make any difference.
Originally I thought it was associated with the -G <gtffile> flag, but now I am getting it for runs even without this flag.

It is an odd error because it seems to be data-dependant. The same command-line, run on two different sets of 100bp paired end data (even if one is just a trimmed version of the other), can result in one set running smoothly and the other failing.

If anyone has any insights on this I'd love to hear it. Failing that, I think its time for a move to STAR

[bruce01]

If you want to get support on your issues from the developer(s), use STAR. Also it is much faster than Tophat.

[Bukowski]

I have to say I am currently loathe to upgrade any components in my RNA-Seq pipelines because every release seems to have an issue that someone hits.

The lack of engagement from the authors of this particular suite is quite stunning given how widely used it is.

We are also assessing STAR

[Brian Bushnell]

I'd like to suggest BBMap. It's faster, more stable, and more accurate than TopHat (I can't say anything about Star, haven't used it). For RNAseq, this command would work:

bbmap.sh ref=reference.fa in=reads.fq out=mapped.sam maxindel=100000 xstag=ss intronlen=10

That produces Tophat-like output, with XS tags (needed by cufflinks) set to second-strand protocol. Alternatively there is xstag=us (unstranded) and xstag=fs (firststrand).