[arkanion]

htseq-count bug

I have tried the above suggestion changing the limit to 30G but still get the same error.

Any fix yet?

[fanli]

It's a really easy fix. Editing my file (yours may be in a different location):

sudo vim +625 /usr/lib64/python2.7/site-packages/HTSeq-0.6.1p1-py2.7-linux-x86_64.egg/HTSeq/__init__.py

in vim, replace the max_buffer_size default setting (my new setting is bolded):

def pair_SAM_alignments_with_buffer( alignments, max_buffer_size=[B]30000000[/B] ):

[pengchy]

Maybe we just need a more work to sort the bam file according to read name "samtools sort -n"

[SrCardgage]

disheartening

It's rather disheartening that this has been a known issue for more than a year and there is still no fix.

I just switched to DESeq from Cufflinks and am learning my THIRD method of generating the counts matrix to feed into DESeq.

I'm beginning to wonder if any published bioinfo tools are actually usable in the real world.

[catbus]

P.S. subread only takes about 10 minutes to install. It doesn't have any complicated dependencies. Once again: http://subread.sourceforge.net/

[catbus]

Two options:

You can either re-sort your files lexographically/alphabetically and run htseq-counts with the lexigraphic order (in other words, NOT --order=pos)

or

You can switch to the much faster and generally more user friendly (easier options, easier output file format) program "featureCounts". Part of the "subread" package. http://subread.sourceforge.net/

I would switch to subread. htseq-counts is incredibly slow and very poor at handling large files without crashing.


[QUOTE=dc3000;161213]Is there a way to increase the buffer size?

I got this error with a pos-sorted.bam file (3.2GB) created with tophat2

[CODE]
[xxx@dev-intel14-phi 20131017mRNA_gfCC]$ htseq-count --format=bam --stranded=no --order=pos \

[dc3000]

Is there a way to increase the buffer size?

I got this error with a pos-sorted.bam file (3.2GB) created with tophat2

[xxx@dev-intel14-phi 20131017mRNA_gfCC]$ htseq-count --format=bam --stranded=no --order=pos \
> ~/RTSF/hiseq/20131017mRNA_gfCC/ms12cc2/accepted_hits.bam \
> ~/RTSF/hiseq/20131017mRNA_gfCC/genes.gtf \
> > ~/RTSF/hiseq/20131017mRNA_gfCC/htseq/ms12cc2.txt
100000 GFF lines processed.
...
16100000 SAM alignment record pairs processed.
16200000 SAM alignment record pairs processed.
Error occured when processing SAM input (record #35593187 in file /mnt/home/xxx/RTSF/hiseq/20131017mRNA_gfCC/ms12cc2/accepted_hits.bam):
  Maximum alignment buffer size exceeded while pairing SAM alignments.
  [Exception type: ValueError, raised in __init__.py:671]
[xxx@dev-intel14-phi 20131017mRNA_gfCC]$ Write failed: Broken pipe

[golharam]

I get this problem as well using tophat2 aligned BAM files, position sorted. I will revert to name sorting.

[catbus]

It appears that this problem is not addressed in 0.6.1p2 either.

It would be extremely nice if there were a way to use htseq-count on positionally-sorted data (which is the default Tophat output). Maybe there could be an option that htseq-count could use to just increase the buffer size? I have 48 GB of RAM on this machine, so it is not possible that htseq-count could actually consume it all on one file.

[dakl]

I get the same with reads aligned with star, and position sorted using samtools.

tools/samtools view /home/daniel.klevebring/cust001/tests/fullRNA/L8760/rnaseq/L8760T/L8760T.star.50.stranded.PE.bam 
| htseq-count  --stranded=reverse --mode=intersection-nonempty  --order=pos - /mnt/hds/proj/cust001/autoseq_genome/genes/genes_fixed.gtf > /home/daniel.kleveb
ring/cust001/tests/fullRNA/L8760/rnaseq/L8760T/L8760T.star.50.stranded.PE.htseq-count.txt

...
18900000 SAM alignment record pairs processed.
Error occured when processing SAM input (line 40808946):
  Maximum alignment buffer size exceeded while pairing SAM alignments.
  [Exception type: ValueError, raised in __init__.py:671] 

$ htseq-count |grep version
Public License v3. Part of the 'HTSeq' framework, version 0.6.1p1.

I don't always get it, and it runs with larger files without a problem. What's the best fix for this? Is there one?

[sidderb]

As Simon reads these I just wanted to flag up that I have run into the same issue with a position sorted alignment from STAR as well.

I was so excited to see this feature in 0.6 as the position to name based ordering is an annoyingly long step in my workflow! Fingers crossed for a fix soon...

[mehaffeymg]

Working now

When you used the name-sorted file, have you remembered to omit the "-r pos"?

Excellent catch. I reran without that flag and it worked just fine.

Thank you!

[Simon Anders]

When you used the name-sorted file, have you remembered to omit the "-r pos"?

[mehaffeymg]

I get the same "Maximum alignment buffer size exceeded" whether running my bam file as position or name sorted. It gets farther with the name sorted file than the position sorted file (output size of 1 Gb vs. 600+ Mb respectively) but still fails. My input bam is 11Gb of around 142 million reads.

[Bukowski]

Have hit the same problem with STAR aligner, and positional ordering.

12200000 SAM alignment record pairs processed.
Error occured when processing SAM input (record #27408270 in file alignments/S6.bam):
Maximum alignment buffer size exceeded while pairing SAM alignments.
[Exception type: ValueError, raised in __init__.py:671]