Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added lineages BF.7.16 (ORF1a:A498V) and BF.7.16.1 (S:A688V)
- Loading branch information
1 parent
da048f5
commit e55f0c3
e55f0c3There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The path to BF.7.16 is BF > C7279T > C1758T but unfortunately there's a reversion on 7279 on the path to BF.7.16.1:
C7279T > C1758T > T7279C > T2080C > C6633T > C22792T > C23625T
So both BF.7.16 and BF.7.16.1 have C1758T, but only BF.7.16 has C7279T. I think they're more likely siblings than parent/child. Sorry the tree has it wrong there.
e55f0c3There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me check again!
e55f0c3There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a misunderstanding between us. I noticed the flip-flop, it's just a few sequences that have 7279T, it's not meant to be defining for BF.7.16.
You can start it anywhere on that flipflop segment as long as it includes 1758T - that's what makes BF.7.16
BF.7.16 strictly speaking includes the 7279T, but it's not that important.
https://next.nextstrain.org/fetch/genome-test.gi.ucsc.edu/trash/ct/subtreeAuspice1_genome_test_1baf5_aabde0.json?branchLabel=back-mutations&c=gt-nuc_7279,1758,23625&label=id:node_6989367
So red is BF.7.16, yellow is BF.7.16.1, green also belongs to BF.7.16, but if it's better for you to take them out that's fine, doesn't really matter.
Does that make sense?
e55f0c3There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so it would be better for the tree to have the opposite order of C7279T and C1758T:
... > C1758T (BF.7.16) > C7279T > [non-BF.7.16.1 seqs]
... > C1758T (BF.7.16) > T2080C > C6633T > C22792T > C23625T (BF.7.16.1)
I can temporarily take out the sequences with only C7279T and not C1758T, and then reoptimizing should put C1758T first. Then I will have to keep an eye on it to see what happens when the sequences with only C7279T are added back. If matOptimize moves C7279T first again, that would make a good test case for a feature request for matOptimize to not do that. 🙂 (i.e. don't combine branches if it makes a new reversion necessary)