samtools mpileup possible bug

[Ravaf]

Hello,

I noticed that last sample (last 3 columns) in mpileup format behave strangely in positions with low base quality (< 13). It looks like:

0

where it should be:

0 * *

Does anyone have similar issue? Is this a bug?

It confuses my downstream scripts, because there are fewer columns in those positions than expected.

I am using Version: 1.2 (using htslib 1.2.1)

[dgscofield]

It's a longstanding "feature" of samtools mpileup when coverage is 0 because of excluded bases rather than no mapped reads. I would imagine by now there are many scripts that check for this case and they might break if the mpileup were changed. I would simply modify your script to handle this case.

[Ravaf]

It's a longstanding "feature" of samtools mpileup when coverage is 0 because of excluded bases rather than no mapped reads. I would imagine by now there are many scripts that check for this case and they might break if the mpileup were changed. I would simply modify your script to handle this case.

I see, would you happen to know if this "feature" occurs only in last individual, or in your experience - it can occur anywhere? Many thanks for your reply!

[dgscofield]

i believe it can occur anywhere, and i think you may find that the columns may be empty, but their positions are still delimited with tabs. so that instead of

... <tab> 0 <tab> * <tab> * <tab> ...

it is

.... <tab> 0 <tab> <tab> <tab> ...

There is an additional wrinkle if you use the -s flag to include a read mapping quality column in the mpileup. In the case of "0 * *" entries, they are always three columns rather than the expected 4, while the "0 blank blank" entries are the expected four columns "0 blank blank blank".

[jmarshall]

The additional -s wrinkle has been fixed since samtools 1.0.

Thanks for the reminder to revisit the main problem reported here.