rogerjms / bedtools

Automatically exported from code.google.com/p/bedtools
0 stars 0 forks source link

genomeCoverageBed: negative coverage #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Load a sample bam and chr-sizes files from our ftp server
ftp://ftp2.cshl.edu/gingeraslab/tracks/BEDtools/ex1.bam
ftp://ftp2.cshl.edu/gingeraslab/tracks/BEDtools/chrUCSC.sizes

2. run witn -bg
BEDTools-Version-2.8.3/bin/genomeCoverageBed -split -bga -ibam ex1.bam -g 
chrUCSC.sizes > ex1.bga

3. run with -bga
BEDTools-Version-2.8.3/bin/genomeCoverageBed -split -bg -ibam ex1.bam -g 
chrUCSC.sizes > ex1.bg

What is the expected output? What do you see instead?

In -bga case, the coverage column contains negative numbers
In -bg case, some bases that are covered by reads are not present in bedGraph 
file, for example bases 
chr1:91,853,152-91,853,157 - check the reads from the BAM file on UCSC browser:
http://genome.ucsc.edu/cgi-bin/hgTracks?hgS_doOtherUser=submit&hgS_otherUserName
=Alexdobin&hgS_otherUserSessionName=BEDtools%20example

I also run it with -d flag and got the negative coverage as well.

What version of the product are you using? On what operating system?

BEDTools-Version-2.8.3
Linux version 2.6.18-164.9.1.el5 (mockbuild@builder10.centos.org) (gcc version 
4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Dec 15 20:57:57 EST 2009

Original issue reported on code.google.com by adobin@gmail.com on 29 Jul 2010 at 8:30

GoogleCodeExporter commented 9 years ago
Thanks for identifying this and sorry for the delay --- I was on vacation.  It 
looks like my recent changes prevent genomeCoverageBed from handling very deep 
coverage (mistakenly used 2 byte integers instead of 4 byte).  I've fixed it 
and will post the latest release by next Tuesday.  

Thank you for the excellent example and clear description of the issue --- this 
certainly expedites the identification of the bug.

Original comment by aaronqui...@gmail.com on 4 Aug 2010 at 9:05