Hi, I'm writing to report what appears (?) to be a bug in VCF output from SLiM 5.2.
In the VCF produced by the script below, the contig declaration uses the chromosome ID "1":
##contig=<ID=1,URL=https://github.com/MesserLab/SLiM>
However, the CHROM field in the variant records uses the implicit chromosome's symbol, "A":
#CHROM POS ID REF ALT QUAL FILTER INFO FORMAT ...
A 3 . A T 1000 PASS ...
I expected the declared contig ID to match the value used in the CHROM field.
The same header/record mismatch also appears in the example VCF output on page 199 of the updated SLiM 5.2 manual.
You can reproduce this with the script below.
initialize() {
setSeed(12345);
initializeMutationRate(1e-3);
initializeMutationType("m1", 0.5, "f", 0.0);
initializeGenomicElementType("g1", m1, 1.0);
initializeGenomicElement(g1, 0, 999);
initializeRecombinationRate(1e-4);
}
1 early() {
sim.addSubpop("p1", 20);
}
20 late() {
p1.outputVCFSample(
4,
replace=F,
outputMultiallelics=F,
filePath="slim_vcf_header_bug.vcf"
);
community.simulationFinished();
}
Thanks!
Patrick McKenzie
Hi, I'm writing to report what appears (?) to be a bug in VCF output from SLiM 5.2.
In the VCF produced by the script below, the contig declaration uses the chromosome ID "1":
However, the CHROM field in the variant records uses the implicit chromosome's symbol, "A":
I expected the declared contig ID to match the value used in the CHROM field.
The same header/record mismatch also appears in the example VCF output on page 199 of the updated SLiM 5.2 manual.
You can reproduce this with the script below.
Thanks!
Patrick McKenzie