TopHat 2.0.6 problem with number of threads option

[Enrique Zudaire]

Dear colleagues,

I'm using tophat 2.0.6 to RNASeq data. I'm usign all the default options and setting -p 12.
I consistently get the error below.

Several threads in this forums suggest that setting the number of threads to 1 (-p 1) takes care of this problem for tophat versions up to 2.0.4.
Does anyone know if the problem persists in version tophat 2.0.6 and if so is there a workaround other than setting threads to 1? this will dramatically increase the runtime and make usage of resources wasteful.

Thank you all.

Kike


[2013-04-12 23:01:08] Beginning TopHat run (v2.0.6)
-----------------------------------------------
[2013-04-12 23:01:08] Checking for Bowtie
Bowtie version: 2.0.2.0
[2013-04-12 23:01:08] Checking for Samtools
Samtools version: 0.1.18.0
[2013-04-12 23:01:08] Checking for Bowtie index files
[2013-04-12 23:01:08] Checking for reference FASTA file
Warning: Could not find FASTA file /data/zudairee/bowtie2_indexes/mm10/mm10.fa
[2013-04-12 23:01:08] Reconstituting reference FASTA file from Bowtie index
Executing: /usr/local/apps/bowtie/2-2.0.2/bowtie2-inspect /data/zudairee/bowtie2_indexes/mm10/mm10 > /data/zudairee/unaligned/TophatTwoResult-041213-6/tmp/mm10.fa
[2013-04-12 23:04:21] Generating SAM header for /data/zudairee/bowtie2_indexes/mm10/mm10
format: fastq
quality scale: phred33 (default)
[2013-04-12 23:08:28] Preparing reads
left reads: min. length=101, max. length=101, 3999983 kept reads (17 discarded)
right reads: min. length=101, max. length=101, 3999744 kept reads (256 discarded)
[2013-04-12 23:14:39] Mapping left_kept_reads to genome mm10 with Bowtie2
[2013-04-12 23:24:34] Mapping left_kept_reads_seg1 to genome mm10 with Bowtie2 (1/4)
[2013-04-12 23:29:56] Mapping left_kept_reads_seg2 to genome mm10 with Bowtie2 (2/4)
[2013-04-12 23:35:39] Mapping left_kept_reads_seg3 to genome mm10 with Bowtie2 (3/4)
[2013-04-12 23:41:03] Mapping left_kept_reads_seg4 to genome mm10 with Bowtie2 (4/4)
[2013-04-12 23:47:01] Mapping right_kept_reads to genome mm10 with Bowtie2
[2013-04-12 23:57:30] Mapping right_kept_reads_seg1 to genome mm10 with Bowtie2 (1/4)
[2013-04-13 00:02:59] Mapping right_kept_reads_seg2 to genome mm10 with Bowtie2 (2/4)
[2013-04-13 00:09:00] Mapping right_kept_reads_seg3 to genome mm10 with Bowtie2 (3/4)
[2013-04-13 00:14:19] Mapping right_kept_reads_seg4 to genome mm10 with Bowtie2 (4/4)
[2013-04-13 00:19:41] Searching for junctions via segment mapping
[FAILED]
Error: segment-based junction search failed with err =1
Error: could not get read# 3671535 from stream!Error: could not get read# 322609 from stream!!Error: could not get read# 1657762 from stream!

[mastal]

TopHat 2.0.6 problem with number of threads option

Hi,

I have had similar problems with earlier versions of TopHat when the computer ran out of memory.

How big are your read files and how much memory does the computer you are using have?

[Enrique Zudaire]

Hi,

Memory should not be a problem. Right ow I'm assigning 24GB per process and the individual files are ~1.3GB.
Any thoughts?

[smcinturf]

I had a similar problem, perhaps my problem might help you. I was mapping 18 libraries of ~40mil reads/lib on a Linux cluster that I SSH'd onto. The cluster used the PBS/Torque job scheduler to execute large jobs. So when I was submitting my tophat runs, I would run all of them at once and I would get the 'failure to get ... from stream' error. I found that I could map all of my reads if I submitted them one by one. My suspension has been that each user on the cluster is only assigned so much memory the jobs can draw from (before swapping and so forth) and my jobs were running out of memory, so it throws errors. Other schedulers also need to have the memory for each job specified on the submission header.
Summary: check for admin level control on your memory, if your jobs are Actually getting the memory, worst case try mapping one by one to help `debug`, and if you are using a scheduler did you specify the header correctly.

Hope that helps!
Sam