Setting Release-Version v9.9.13
updated version
add check that submodules are downloaded to makefile
Setting Release-Version v0.9.13
another update to version

Make sure it sticks.
changed git:// to https://
Merge pull request #66 from andersje/git_to_http

changed git:// to https://
add warning that region cannot be set on haplotype basis file
fix targeting issue in vcflib, add some more info to allele obs debugging
resolve bug in implementation of Ewens' Sampling Formula

Thanks to Severine Catreux for the catch.

This should have the largest effect on sites that are multiallelic.  The
quality of these will be diminished slightly, in line with the bug.  This may
reduce the overall power to detect variants at multiallelic loci.

It is possible that this is not the most-correct way to utilize the ESF in
freebayes, as the assumption of a constant mutation rate for each locus in the
genome is inadequate.  At some loci the mutation rate is orders of magnitude
higher than elsewhere.  Problematically, these are the same places where
Illumina data (and any PCR-based library) tends to present artifacts.
Setting Release-Version v0.9.14
don't fail when we get a region which has no haplotype basis alleles
swap default GL calculations; add --experimental-gls (replaces --standard-gls)

A number of reports have recently described issues with freebayes genotyping.
These generally appear to stem from the new genotype likelihood calculations
which were implemented and tested primarily in the context of re-genotyping
putative alleles in diploids for the purpose of generating high-quality GLs
suitable for imputation.

Testing has shown that in most cases this change has little effect, but where
it does matter is also where it could be very confusing for users, such as in
polyploid organisms or in low-complexity sequence (where the "experimental" GL
calculation likes to call spurious hets).

The default (previously --standard-gls) is restored.  Now, to obtain the new
behavior you should supply --experimental-gls or provide contamination
estimates or a hard setting of contamination via --prob-contamination.
improve handling of --variant-input

This feature has been mostly broken for some time, superseded instead by
--haplotype-basis-alleles, which targets haplotype construction and genotyping
only to a particular set of alleles.  However, the logic of the haplotype
construction requires observations to support putative haplotype structures,
emitting no information about sites that are called homozygous reference.

To resolve this issue, I have fixed blocking issues for --variant-input, and
now suggest its use in the cases that:

- you want to be sure to make calls at given sites
- you are calling a number of samples or pools singly, and want to merge them
on a given set of known alleles
- you otherwise want to directly interrogate a given BAM file at given positions

--variant-input and --haplotype-basis-alleles are not quite harmonized yet.  I
am still thinking about the correct way to do this.  Nevertheless, it should
now be possible to use the feature as was intended.

To do so, normalize your variant representation by e.g. vt normalize (from
https://github.com/atks/vt).  Remove sample information and allele frequency
(AF) and count (AC) from the input file.  These (AC, AF, GT, GL) can be left if
desired, but they are used as priors when computing the site.  Then tabix index
the VCF and provide it to the algorithm via the --variant-input flag.

If you would like to restrict to only variant-input sites, also supply
--only-use-input-alleles.  Otherwise, calls will be made as normally at sites
and alleles that aren't in the variant-input file.
save a few % of runtime in re-genotyping mode

When --variant-input and --only-use-input-alleles are specified, skip positions
when there are no input alleles.
reminder to cite freebayes using DOI rather than URL
cleanup formatting of README
correct buildHaplotypeAlleles, and clarify --min-mapping-quality

Due to a logic error, buildHaplotypeAlleles was excluding reads that end
exactly at the haplotype window.  Many thanks to Severine Catreux, who made
this catch.

In this commit, -m is changed to (as documented) exclude reads with MQ < the
given value.  It previously was <=.  The default -m is set to 1.  This will
affect users by adjusting the minimum cutoff, which they should increase by 1
for equivalent behavior.
removing version_git.h from source control
add script to help generate regions of even coverage and run in parallel

If you are running freebayes on anything more than a very small dataset, it's
best to run it on multiple regions in parallel, such as using GNU parallel.

When running in parallel, it can be important to generate targets that have
roughly equal amounts of data in them.  This reduces the variance of runtime in
the jobs and thus improves the overall performance of the process.

Now included is a script which will help do this, provided the coverage output
of bamtools.  You can use it like this:

    % bamtools coverage -in sample001.sorted.bam \
      | scripts/coverage_to_regions.py chr20_bit.fa.fai 10
    chr20_bit:0-10092
    chr20_bit:10092-19390
    chr20_bit:19390-29472
    chr20_bit:29472-40012
    chr20_bit:40012-50035
    chr20_bit:50035-59548
    chr20_bit:59548-69820
    chr20_bit:69820-79811
    chr20_bit:79811-89480
    chr20_bit:89480-100001

Here we generate 10 regions in which there is approximately equal coverage.
For larger datasets, it should be sufficient to feed in a few samples or a
downsampled BAM in order to generate the target list.

To use these, one could apply GNU parallel to run freebayes on all the chunks.

    cat regions | parallel -j 24 'freebayes -f ref.fa -r {} input.bam | gzip >outputdir/{}.vcf.gz'

And then merge the chunks afterwards:

    ( zcat outputdir/$(head -1 regions).vcf.gz | grep "^#"   # generate header
      cat regions | parallel -k -j 24 'zcat outputdir/{}.vcf.gz | grep -v "^#"' ) \
      | vcfstreamsort | vcfuniq | bgzip >merged_results.vcf.gz
    tabix -p vcf merged_results.vcf.gz