[ians]

I found the segment_juncs command that died in runs.log.
I tried rerunning the exact command, but with p=1 (singlethreaded), and get the same error.

I've dug through the source of reads.cpp to find that apparently read access must be sequential. Does anyone know which file these reads are listed?

[ians]

I'm still digging through source hoping for some light. Any insight would be strongly appreciated.

[ians]

Solved?

I ran a test run over the weekend using data that had failed before. The run was successful over the weekend!
I ran with just as many threads as the box has. This contrasts with the pervious failed runs where i called for more threads than existed (2x).
I'm optimistic that i'll be able to successfully rerun the other samples as well. I'll let you know if this isn't the case.

[MichalO]

seems to be a really random issue... I have it in one sample only - three others have been run happily. I'm curious about the explanation

[ians]

For me it was pretty systematic.

My solution seems to work thus far as I have rerun 3 samples that previously failed.

I think the problem may stem from when Cufflinks' threads are competing at the scheduler with other processes. Many time people report this error when they share compute resources on a cluster. Perhaps this ordering is basically a race condition where threads can become out of sync, resulting in unexpected orders of return.

[Auction]

I was wondering If you still see the problem with the latest code build of tophat2?

I just ran tophat2.0.4 with around 60M reads, still got the same error in tophat_reports step
Error: ReadStream::getRead() called with out-of-order id#!

[tejaswi.iyyanki]

Multi threading causes problem for me

srun -S 32 tophat -p 32 -G <.gtf> -o <folder/> <hg19> *.fastq.gz

The above code gives me error:
Error: segment-based junction search failed with err =1
Error opening SAM file <folder/>/tmp/right_kept_reads.m2g_um_seg1.bam

The following code didnot give me any error!
srun -S 32 tophat -p 32 -G <.gtf> -o <folder/> <hg19> *.fastq.gz --no-coverage-search

[ronaldrcutler]

I ran a test run over the weekend using data that had failed before. The run was successful over the weekend!
I ran with just as many threads as the box has. This contrasts with the pervious failed runs where i called for more threads than existed (2x).
I'm optimistic that i'll be able to successfully rerun the other samples as well. I'll let you know if this isn't the case.

What do you mean by as many threads as the box has? I am getting a similar error but use this command to determine how many threads I have to set for p.

sysctl -n hw.ncpu

Currently I'm going along the lines of increasing the amount of open files that can be open as described here

[Brian Bushnell]

Why are you even using Tophat? Even the group that developed it does not recommend it anymore. There are numerous superior alternatives. The group that developed Tophat now recommends HISAT, which they developed. I recommend BBMap, which I developed. But I don't think anyone recommends Tophat.

[ronaldrcutler]

I'm doing comparisons of old analysis in which we used tophat2. Though you are right, I have been using hisat2 (really fast) and have indeed just started today on using BBmap to compare amongst aligners.