Disagreement of results with samtools and bedtools

[apozomt]

Dear,

We have being testing the performance of mosdepth and we came across with some disagreement that we are not able to explain.

The mean depth (calculated with per-base file in ROI region) is below the value that we get with bedtools and samtools. These last two tools agree one to each other. To make sure that we are certainly adding the alignments that we want, first we select them with samtools view (-Q20 -F4).

The difference is bigger as the mean depth of the sample raises.

We have tuned the tool with the parameters of quality and the off of some bam flags with no success

For some reason, mosdepth does not sum certain aligmnents but we can't guess the criteria.

Can someone help us?

some of the results are:

sample	Depth (bedtools genomecov)	Depth Mosdepth Q20 -F4	Diff
S1	226.35	140.17	86.18
S2	282.6	201.94	80.66
S3	22.1	13.59	8.51
S4	321.53	232.04	89.49
S5	302.2	200.68	101.52
S6	463.69	309.07	154.62
S7	1712.59	1218.7	493.89
S8	283.97	193.77	90.2
S9	565.61	384.24	181.37
S10	318.84	228.56	90.28
S11	498.36	330.7	167.66
S12	1023	719.74	303.26
S13	1084.31	759.14	325.17
S14	263.12	187.77	75.35
S15	288.81	209.73	79.08
S16	883.44	643.81	239.63
S17	572.41	434.08	138.33
S18	1423.13	1046.05	377.08

In addition, we have checked the results base by base and the difference with respect to IGV is clear. The example shows a base that is 1165X and mosdepth output is 828X:

[brentp]

there are several other issues related to this. mosdepth does not double-count overlapping bases. bedtools does (I assume IGV does as well). For every issue like this one that has provided data, I have checked and never found a bug in mosdepth.

mosdepth will often have lower depth than bedtools because bedtools double-counts overlapping bases--it may also use different include/exclude flags

mosdepth will often have a higher depth than samtools depth, but samtools depth and samtools mpileup often do not agree even for identical parameters.

[kkapuria3]

Can we run mosdepth to double-count overlapping bases ?

[brentp]

the next-release of mosdepth will have a mode that does not correct for mate-overlap.

[kkapuria3]

That would be really great. How soon can we expect this release ?

[brentp]

The new release is out with --fast-mode that will not correct for overlapping mates.

[asmlgkj]

I am a lillte confused, but I am sure you are right.
the accumlated depth is because of reads overlap, so here does not take overlap means the overlap will be calculated as many times as overlaped reads multiply 2 ?

[brentp]

this is only relevant when a read-pair from the same fragment (with same read-id) overlaps.