VCF output from FreeBayes

[cigsit]

Hi,

I have just started using FreeBayes as a comparison to samtools as they both take BAMs and produce a VCF output which is ideal for scripting. FreeBayes actually seems like the ideal free-standing, simple and fast SNP caller I have been longing for, however the values in the VCF INFO column do not seem to match what is in the alignment.
In particular the DP value almost never seems to match what I can see in alignment viewers. It is always less than the number of reads I see stacked at the SNP position while VCFv4.1 claims that DP should represent the _total_ read depth.
Additionally, the AC (Total number of alternate alleles in called genotypes) and AN (Total number of alleles in called genotypes) values seem to almost never vary no matter what the read depth and number of alt alleles at a SNP position. To be more precise AC is always either 1 or 2 and AN seems fixed at 2 no matter what.

Is this a known quirk of FreeBayes? These are very important values that I need to parse from the VCF output but they just make no sense after having used samtools for a few years.

Thanks.

[garwuf]

I have run Freebayes on some of my old bam alignments, which were already evaluated with samtools, gigabayes and gatk. None of the polymorphisms discovered by Freebayes matched the real ones. Actually, it missed very well defined snps, and pointed instead at some positions, which do not look anything special. DP doesn't correspond to real coverage either (no matter if to consider quality or not). Maybe just a problem with old bam formats?

[VeBeKay]

I have similar issues with the freebayes output.
I guess that "AC" & "AN" refer to the number of *alleles* rather than sequencing depth (which is why they are always 1 or 2). (??)
However, I cannot find any documentation of what these or the other fields in the vcf output mean; not all of them are specified here:

http://www.1000genomes.org/wiki/Analysis/Variant%20Call%20Format/vcf-variant-call-format-version-41

If there's any way to get an output from freebayes that looks more like the vcf format of samtools mpileup, I'd be interested to know.

[ekg]

I have run Freebayes on some of my old bam alignments, which were already evaluated with samtools, gigabayes and gatk. None of the polymorphisms discovered by Freebayes matched the real ones. Actually, it missed very well defined snps, and pointed instead at some positions, which do not look anything special. DP doesn't correspond to real coverage either (no matter if to consider quality or not). Maybe just a problem with old bam formats?

I'd guess this is a problem with BAM format changes or the specific (older) version which you were using, but I'm not sure. This sounds pretty strange--- we don't see this at all in testing and if we did we certainly couldn't use freebayes as a detector if it behaved like this.

What happens with this data when you use the most recent version?

[ekg]

Hi,

I have just started using FreeBayes as a comparison to samtools as they both take BAMs and produce a VCF output which is ideal for scripting. FreeBayes actually seems like the ideal free-standing, simple and fast SNP caller I have been longing for, however the values in the VCF INFO column do not seem to match what is in the alignment.
In particular the DP value almost never seems to match what I can see in alignment viewers. It is always less than the number of reads I see stacked at the SNP position while VCFv4.1 claims that DP should represent the _total_ read depth.
Additionally, the AC (Total number of alternate alleles in called genotypes) and AN (Total number of alleles in called genotypes) values seem to almost never vary no matter what the read depth and number of alt alleles at a SNP position. To be more precise AC is always either 1 or 2 and AN seems fixed at 2 no matter what.

Is this a known quirk of FreeBayes? These are very important values that I need to parse from the VCF output but they just make no sense after having used samtools for a few years.

Thanks.

I believe I know what's going on here.

In the old versions, freebayes was designed to behave like gigabayes/bambayes, which used BQ and MQ filters to remove a lot of low-quality reads.

However, this was ultimately shown to be a bad idea, and so the default filters were removed. I think a lot of users got very poor results when their MQs weren't well-calibrated. (I eventually settled on minimum input filters requiring at least 2 observations comprising 20% of reads in a single individual, which I've just made default in the recent freebayes revisions.)

So, the point is that the reported DP is the post-filter depth. And, if you were running with a minimum mapping quality filter of 30 and a minimum base quality filter of 20, the DP might get quite low.

If you run with the most recent version, you should get results that are more sensible.