Question: bedtools coverage gives error received illegal bin number, but that number isn't in my data!
2
gravatar for tara.alpert
2.0 years ago by
tara.alpert30
tara.alpert30 wrote:

I am trying to calculate the coverage of a ChIP data set over a very limited set of gene coordinates. I have very simple bed files for both (after trying to eliminate any cause of the error) that are just the bare bones "chr start end" columns, and every time I run the command:

bedtools coverage -a a.bed -b b.bed

I get this error:

ERROR: Received illegal bin number 4294967295 from getBin call.
ERROR: Unable to add record to tree

I used grep to search for this number and it's nowhere to be found in either of my files, which makes sense given that my genome isn't that big. So why am I still getting this error???

Thanks for your input!

ADD COMMENTlink modified 28 days ago by pangxy30 • written 2.0 years ago by tara.alpert30
3

4294967295 is a special number. Maybe an overflow error somewhere with an unsigned integer.

ADD REPLYlink written 2.0 years ago by Alex Reynolds27k

Hmm interesting, could you explain a little more? I'm not terribly experienced yet.

ADD REPLYlink written 2.0 years ago by tara.alpert30
1

It's not your fault, probably, but when you see that number pop up, it usually indicates that an unsigned integer is being used incorrectly to store a negative number (which is signed).

ADD REPLYlink modified 2.0 years ago • written 2.0 years ago by Alex Reynolds27k

Ok, thanks so much. Any idea how to correct it?

ADD REPLYlink written 2.0 years ago by tara.alpert30

No idea. You might contact the developers.

ADD REPLYlink modified 2.0 years ago • written 2.0 years ago by Alex Reynolds27k
1

Can you provide a few lines of those BED files?

ADD REPLYlink written 2.0 years ago by igor7.3k

a.bed

chrI   1001       1080
chrI   1003       1076
chrI   1008       1102

b.bed

chrI   143160   143210
chrII  126119   126169
chrII  142868   142918
ADD REPLYlink modified 2.0 years ago • written 2.0 years ago by tara.alpert30
4
gravatar for igor
2.0 years ago by
igor7.3k
United States
igor7.3k wrote:

The BED files look reasonable.

Maybe there are invisible characters somewhere in the file? Can you try running mac2unix or dos2unix on them?

ADD COMMENTlink modified 2.0 years ago • written 2.0 years ago by igor7.3k
1

This resolved the error... THANK YOU SO MUCH!

ADD REPLYlink written 2.0 years ago by tara.alpert30

Hi ! I have the same problem ! could you please show the command you used with mac2unix to solve it ? thanks

ADD REPLYlink written 8 months ago by ataaillah0

worked for me also! thanks!

ADD REPLYlink written 21 months ago by orlando.wong60

I have the same error, it turns out that my bed file has positions reversed. So start coordinate was higher than stop.

ADD REPLYlink written 15 months ago by boczniak767620
1
gravatar for Alex Reynolds
15 months ago by
Alex Reynolds27k
Seattle, WA USA
Alex Reynolds27k wrote:

You can use bedops --ec <options> to do sanity checks on BED input:

$ echo -e 'chrZ\t123\t123' | bedops --ec --everything -
May use bedops --help for more help.

Error: in stdin
End coordinates must be greater than start coordinates.
See row: 1

The --ec makes operations take longer to complete, but it can be useful for identifying these and other common interval problems. For instance, non-Unix line endings in three-column BED:

$ echo -e 'chrZ\t123\t124\r' | cat -te
chrZ^I123^I124^M$

A bedops --ec run will report problems with the end coordinate:

$ echo -e 'chrZ\t123\t124\r' | bedops --ec --everything -
May use bedops --help for more help.

Error: in stdin
End coordinate contains non-numeric character:
See row: 1

You can then use awk or dos2unix or similar to clean up your BED.

The --ec option is also available in bedmap, as well as bedops.

Once you can "trust" that your BED data are "clean", you can remove the --ec option and recover the performance improvements.

ADD COMMENTlink modified 15 months ago • written 15 months ago by Alex Reynolds27k
0
gravatar for soloway
21 months ago by
soloway0
soloway0 wrote:

I got the very same error code using bedtools intersect.

I used the following bash command to remove non-alpha numerical characters from bed1.bed. The resulting bed2.bed did not throw an error.

bed1.bed | sed "s/\W\W/\t/g" > bed2.bed

I did have strand info (+ or -) that was removed in the process.

ADD COMMENTlink modified 6 weeks ago by RamRS20k • written 21 months ago by soloway0
0
gravatar for apa@stowers
18 months ago by
apa@stowers390
Kansas City
apa@stowers390 wrote:

This can also happen if you have double-0 intervals, AND are using bedTools > 2.24.0.

Basically if one of your bed files has a line like

chrX  0  0  ...

intersectBed v2.24.0 will run it successfully, but intersectBed v2.26.0 will throw the error

Received illegal bin number 4294967295

yes with that exact same number 4294967295. At least, it did that on my CentOS7 box.

I prevent this by running something like:

cat original.bed | awk '{ if ($2!=$3) print $0 }' > fixed.bed

since BED data is 0-based and thus should never have start == end anyway...

ADD COMMENTlink modified 6 weeks ago by RamRS20k • written 18 months ago by apa@stowers390
0
gravatar for brianpenghe
14 months ago by
brianpenghe20
United States
brianpenghe20 wrote:

I got the same error and the cause was a little bit different:

In the bed file I downloaded there were lines with third column missing!

chr1    3139719
chr1    12645719
chr1    12959919
chr1    14960519
chr1    24616961
chr1    24808855
chr1    26688455
chr1    33991955
chr1    63630926
chr1    73551026

That file was claimed to be derived from UCSC liftover. So I suppose liftover program might have produced something partial?

ADD COMMENTlink modified 14 months ago by genomax62k • written 14 months ago by brianpenghe20
0
gravatar for pangxy3
28 days ago by
pangxy30
pangxy30 wrote:

I got same error when using subtract of bedtools. And I have tried to use bedops to check one of my input file:

bedops --ec --everything final.utr.raw.bed

I got this:

chr1    14361   29370   WASH7P_mergedExon_1 15010   -
chr1    17368   17436   MIR6859-1_mergedExon_1  69  -
chr1    29925   31295   LOC107985730_mergedExon_1   1371    +
chr1    30365   30503   MIR1302-2_mergedExon_1  139 +
chr1    34610   36081   FAM138A_mergedExon_1    1472    -
May use bedops --help for more help.

Error: in final.utr.raw.bed
End coordinates must be greater than start coordinates.
See row: 8

Then I used awk to delete illegal lines

awk '($2<$3){print $0}' final.utr.raw.bed > final.utr.bed

then subtract got right answer.

ADD COMMENTlink modified 28 days ago by finswimmer9.9k • written 28 days ago by pangxy30

You can also use awk to fix the input before running it through bedops:

$ awk -vFS="\t" -vOFS="\t" '{ if ($2 == $3) { $2--; } if ($2 > $3) { t = $3; $3 = $2; $2 = $3; } print $0; }' final.utr.raw.bed | sort-bed - | bedops --operations ... > answer.bed

You don't necessarily need to delete "illegal" lines, although you could if it makes sense to do so.

ADD REPLYlink modified 28 days ago • written 28 days ago by Alex Reynolds27k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.3.0
Traffic: 1150 users visited in the last hour