sambamba base output missing chunks of data

[parlar]

Hi!

The output from sambamba depth base 0.6.2 (and earlier versions) is missing chunks of data. I used the -z option. The bam was sorted but to make sure that it really was I sorted it again using sambamba sort.

Here is an example. Notice the gap between pos 775 and 1860.

chrM 768 2 0 2 0 0 0 0 16-3584
chrM 769 2 2 0 0 0 0 0 16-3584
chrM 770 2 0 0 2 0 0 0 16-3584
chrM 771 1 0 1 0 0 0 0 16-3584
chrM 772 1 1 0 0 0 0 0 16-3584
chrM 773 1 1 0 0 0 0 0 16-3584
chrM 774 1 0 0 0 1 0 0 16-3584
chrM 775 1 0 0 1 0 0 0 16-3584
chrM 1860 15 15 0 0 0 0 0 16-3584
chrM 1861 15 15 0 0 0 0 0 16-3584
chrM 1862 15 0 0 0 15 0 0 16-3584
chrM 1863 15 0 0 0 15 0 0 16-3584
chrM 1864 15 15 0 0 0 0 0 16-3584
chrM 1865 30 30 0 0 0 0 0 16-3584
chrM 1866 30 0 30 0 0 0 0 16-3584

As a comparison I ran bedtools genomecov, which outputs correctly depth readings for all positions.

[lomereiter]

Hi,

Does it help if you add -c 0 option? It defaults to 1 (sorry, I know documentation for depth is terrible).

[parlar]

Nope. Same thing (below).

I ran it like this:

sambamba62 depth base -c 0 -z -t 8 -F "" 16-3584-ready.sorted.bam >tmp.txt

Have tried other filter options also.

chrM 769 2 2 0 0 0 0 0 16-3584
chrM 770 2 0 0 2 0 0 0 16-3584
chrM 771 1 0 1 0 0 0 0 16-3584
chrM 772 1 1 0 0 0 0 0 16-3584
chrM 773 1 1 0 0 0 0 0 16-3584
chrM 774 1 0 0 0 1 0 0 16-3584
chrM 775 1 0 0 1 0 0 0 16-3584
chrM 1860 15 15 0 0 0 0 0 16-3584
chrM 1861 15 15 0 0 0 0 0 16-3584
chrM 1862 15 0 0 0 15 0 0 16-3584
chrM 1863 15 0 0 0 15 0 0 16-3584
chrM 1864 15 15 0 0 0 0 0 16-3584
chrM 1865 30 30 0 0 0 0 0 16-3584

[parlar]

I just emailed you a slice of a bam file that might be useful for tracking down the problem.

cheers

[lomereiter]

Should be fixed now.
Just in case, the test file is the one you've sent, but with randomly generated read bases.

[parlar]

That fixed it! I notice, however, that depths obtained using bedtools genomecov and sambamba 0.6.2 (the new 0.6.2) sometimes differ slightly. Don't know which one is correct, however.

WIll you make a 0.6.3 release? Seems to me as a quite important bug that you fixed here.

[lomereiter]

IMO the best way to check is to find differences in low-coverage regions and check reads at a particular base manually.