Open mwykes opened 1 year ago
Update on this - I just used an alternative tool to decode variants from prefix.hap1.bam to vcf and the resulting vcf looks fine (no Ns) and consistent with the alignments (see IGV screenshot).
medaka tools consensus2vcf hap1.fa.gz ref.fa.gz --bam prefix.hap1.bam --out_prefix medaka_consensus2vcf.hap1
So it suppose this might point to an issue with htsbox pileup?
I'm seeing N's in my dipcall v0.3 vcf where there are not Ns in the reference.
The variants lie within the high confidence bedfile.
Any idea what could be going wrong?
Looking in IGV, the transition to the dense block of variants with ref Ns is not due to the start of a new alignment - and the variants with N as reference are not supported by the haplotype specific assembly to ref alignments.