Closed zach-hensel closed 3 years ago
Also possibly some not being called looking at this UShER tree - https://nextstrain.org/fetch/genome.ucsc.edu/trash/ct/subtreeAuspice1_genome_2cea9_cccf80.json?c=pango_lineage&label=nuc%20mutations:A11456G,G29050A
I think this would be more clear if built masking G142D.
Also possibly some not being called looking at this UShER tree -
Pangolin gets run on a slightly ad-hoc way in the UShER metadata ~so I think you may be seeing old samples here that haven't been re-run since AY.3 was designated. (But I could be wrong).~
Ed: sense checked some seqs and did get B.1.617.2 from Pangolin GUI
You're not wrong, Theo! I do need to re-run pangolin/pangoLEARN on all sequences for the UShER/hgPhyloPlace metadata since the recent pangoLEARN and pangolin releases. But thanks for pointing out that there are multiple possible causes. :)
Thank you both for the background info -- I 100% have no idea how this works which is why I copied the other post. I saw Japan was tracking AY.3 already and since it's not clear there's much if any transmission advantage (still watching fraction of Delta sequences in Missouri and Kansas) there's maybe a small risk in misclassifications having consequences a la UK-Portugal and AY.1 leading to a week of noise when we maybe should've focused on the signal. Also maybe of note for AY.1 and K417N in Delta is @insapathogenomics latest report: https://insaflu.insa.pt/covid19/relatorios/INSA_SARS_CoV_2_DIVERSIDADE_GENETICA_relatorio_situacao_2021-07-13.pdf
On GISAID, there are currenlty (2021/08/04) still 11,088 samples without ORF1ab:I3731V assigned to AY.3, while only 3,783 samples assigned to AY.3 actually contain the mutation.
Thanks @zach-hensel and @phwanka. It looks like there's another B.1.617.2 subclade that has convergently acquired one of the mutations that was acquired leading to AY.3 which is potentially what has resulted in these sequences being assigned AY.3 despite clustering elsewhere. We're currently working on designating lineages within B.1.617.2 which should hopefully resolve this. We'll hopefully post an update soon
If this is possible, a patch to change AY.3 calls to B.1.617.2 calls if missing A11456G (NSP6_I162V, ORF1a:I3731V) mainly fixes the issue for now.
Honestly it's not so bad that a lot of transiently miscalled AY.3 led to people spend a week question why lineage counts can change before jumping to conclusions... this is one of the easier reasons to explain.
Blatantly copied title & text from #140