Open arianna-smith opened 4 months ago
This is caused by a quirk of applying variants iteratively to the reference, I'll have to think about how to handle this case properly, medaka introducing nonsense frameshifts like this is a little concerning though...
There's definitely some indications that using medaka for r10.4.1 data might actually be counterproductive for hac/sup basecalling https://rrwick.github.io/2023/05/05/ont-only-accuracy-with-r10.4.1.html.
Any thoughts on the medaka side @cjw85 @samstudio8?
medaka introducing nonsense frameshifts like this is a little concerning though
Medaka (like many variant callers) contains no explicit knowledge of biology so the attribution of a variant it proposes leading to a frameshift is not unsurprising. My recollection is that fieldbioinformatics explicitely excludes indels that aren't a multiple of 3 bases long?
This is caused by a quirk of applying variants iteratively to the reference
Medaka is fundamentally a consensus caller, not a variant caller in the modern sense that people typically understand. To produce a VCF file, medaka:
(There's some subtleties in 4. to do with specifics of the VCF spec, and ensuring left alignment and variant normalization).
It should be the case that bcftools consensus
can always be run on the output of medaka variant
; I would be interested to examine a data from a case where that appears to not be true.
That's a good point re filtering out of frame indels, the variants in sample.2.vcf
shouldn't have made it into sample.pass.vcf.gz
due to the variants having been removed by vcf_filter
, are you able to share the pass variants file rather than the merged one (merged VCF is produced pre vcf_filter)?
@BioWilko @cjw85 Here is the only one of those three mutations from the pass.vcf file
CHROM | POS | ID | REF | ALT | QUAL | FILTER | INFO | FORMAT | SAMPLE |
---|---|---|---|---|---|---|---|---|---|
MN908947.3 | 669 | . | GT | G | 500 | PASS | DP=1126;AC=2,44;AM=1080;MC=0;MF=0.0;MB=0.0;AQ=4.42;GM=1;PH=6.02,6.02,6.02,6.02;SC=None; | GT:GQ:DP:PS:UG:UQ 1/1:103:1126:.:1/1:102.88 |
There's definitely some indications that using medaka for r10.4.1 data might actually be counterproductive for hac/sup basecalling https://rrwick.github.io/2023/05/05/ont-only-accuracy-with-r10.4.1.html.
@BioWilko Ah, I don't think we were aware of this. Thanks for linking this paper.
When running
artic minion --medaka
, we are occasionally running into an issue where there are overlapping pass variants from the different read groups that is causing bcftools consensus to fail and an empty consensus file is generated. I did see similar issues 1, 2, but those seem to be caused by an overlap of a pass and fail variant.We have had this issue on two medaka models, r1041_e82_400bps_hac_v4.2.0 and r941_min_hac_g507, but did not encounter this issue with the model r941_min_high_g360. The models have been updated alongside our basecaller and have been confirmed with
medaka tools resolve_model --auto_model
.Log: Running:
bcftools consensus -f sample.preconsensus.fasta sample.pass.vcf.gz -m sample.coverage_mask.txt -o sample.consensus.fasta
The fasta sequence does not match the REF allele at MN908947.3:669: REF .vcf: [GT] ALT .vcf: [G] REF .fa : [GN]TAC......... Command failed:bcftools consensus -f sample.preconsensus.fasta sample.pass.vcf.gz -m sample.coverage_mask.txt -o sample.fasta
sample.primertrimmed.rg.sorted.bam:![Screenshot 2024-02-16 164332](https://github.com/artic-network/fieldbioinformatics/assets/94877138/f1d37338-7cef-4693-822f-f2ad0d923b8c)