Another JN.1 + FLiRT lineage emerged in the Iberian Peninsula (Now LF.6) with a S:Q493E branch (2, Spain)

[FedeGueli]

Click to see the original proposal designated **LF.6**

Previously tracked as Branch 133 **FLiRT** of https://github.com/sars-cov-2-variants/lineage-proposals/issues/1089

JN.1 > T17859C > T3172G > S:R346T (G22599C), S:F456L (T22928C)
Query: G22599C, T22928C, T17859C, T3172G, T3565C
Samples: 6 (Portugal 4, Spain 2)
First collected in Madrid on 2024-03-22
IDs:EPI_ISL_19050411, EPI_ISL_19132939, EPI_ISL_19135497,
EPI_ISL_19135500-19135501, EPI_ISL_19135503
Tree:

https://nextstrain.org/fetch/genome-test.gi.ucsc.edu/trash/ct/subtreeAuspice6_genome_test_36311_3cdc50.json?c=gt-S_346,456&gmax=25384&gmin=21563&label=id:node_6984442

Query for the 493E singlet branch spotted by @NkRMnZr : C23039, T17859C, T3172G, T3565C count: 1
Query for TRIO branch Spotted by @aviczhl2 : T19104A ,C23277T,T3565C count: 3

Sublineage of LF.6 spotted by @NkRMnZr ( all credits for the analysis to him)
LF.6 >> A871G > S:Q493E (C23039G)
Query for the 493E singlet branch spotted by @NkRMnZr : C23039, T17859C, T3172G, T3565C
Samples: 2
country: Spain
tree:
https://nextstrain.org/fetch/genome.ucsc.edu/trash/ct/subtreeAuspice51_genome_1a12c_d72dc0.json?label=id:node_11644668

[FedeGueli]

+2 Spain

[FedeGueli]

12 +1 uk

[FedeGueli]

19 multiple provinces of Spain

[FedeGueli]

35 now also in Israel and Ireland

[FedeGueli]

+5 ( 4 Portugal 1 Galicia)

[FedeGueli]

56 now, expanding in the course of the ongoing wave in Spain and Portugal

[NkRMnZr]

EPI_ISL_19243497 one with S:Q493E

[DailyCovidCases]

76 seqs now
Tracked in tracker99
Is it worth to be designated? @corneliusroemer

[aviczhl2]

There is a new S:T572I Trio branch emerged from this.

@corneliusroemer This also deserve designation.

[DailyCovidCases]

@corneliusroemer

[FedeGueli]

There is a new S:T572I Trio branch emerged from this
I don't see any (with G22599C, T22928C, T17859C, T3172G, T3565C):

[aviczhl2]

https://nextstrain.org/fetch/genome-test.gi.ucsc.edu/trash/ct/subtreeAuspice267_genome_test_151ba_201c20.json?gt=S.572I&label=id:node_5453328

[FedeGueli]

https://nextstrain.org/fetch/genome-test.gi.ucsc.edu/trash/ct/subtreeAuspice267_genome_test_151ba_201c20.json?gt=S.572I&label=id:node_5453328

oh what is your query i cant find any with mine.

[FedeGueli]

132

[DailyCovidCases]

135 seqs now:
usher

@corneliusroemer suggest to designate some trajectory of this

[DailyCovidCases]

This branch might be dying off, please close it

[aviczhl2]

This one is 141 now, with quite a few uploaded recently. This shouldn't be closed.

@FedeGueli Please ignore advices from DaliyCovidCases. He seems to be using some weird criteria.

[FedeGueli]

This one is 141 now, with quite a few uploaded recently. This shouldn't be closed.

@FedeGueli Please ignore advices from DaliyCovidCases. He seems to be using some weird criteria.
Yeah for sure, but i was closing it becuase not expanding further, lets keep it open for a while more tough

[aviczhl2]

It is designated LF.6 as a sub-branch of JN.1.16.1. Shall be independent branch.

[FedeGueli]

LF.6 from 8b27ff6

[AngieHinrichs]

@DailyCovidCases can you state your criteria for determining that a branch is dying?

Also, a bit of advice: when your comments are the same word-for-word, it gives the impression that you are running a script instead of critically evaluating the data. I think it would help a lot to include your reason for judging a branch as dying. For example, "This branch has had no new sequences since <date>, and since it was circulating in that uploads sequences <regularly/monthly/sporadically/etc>, I would expect to have seen more sequences by now." But not exactly in those words -- please tell us what you're thinking. 🙂 And then if FedeGueli or others tell you that your criteria need to be more complicated, then next time show that you applied the more complicated criteria.

[DailyCovidCases]

@DailyCovidCases can you state your criteria for determining that a branch is dying?

Also, a bit of advice: when your comments are the same word-for-word, it gives the impression that you are running a script instead of critically evaluating the data. I think it would help a lot to include your reason for judging a branch as dying. For example, "This branch has had no new sequences since <date>, and since it was circulating in that uploads sequences <regularly/monthly/sporadically/etc>, I would expect to have seen more sequences by now." But not exactly in those words -- please tell us what you're thinking. 🙂 And then if FedeGueli or others tell you that your criteria need to be more complicated, then next time show that you applied the more complicated criteria.

My criteria: 6 weeks with 0 sequences updated and the branch will be counted as dead. Is it too quickly?

[AngieHinrichs]

My criteria: 6 weeks with 0 sequences updated and the branch will be counted as dead. Is it too quickly?

6 weeks sounds reasonable to me for countries that have a shorter lag time from sample collection to release of sequences, like only a few weeks. I think @FedeGueli has explained in a different issue that unfortunately many countries, especially countries with fewer resources, may take more than a month to get sequences and release them publicly. So I think it depends on the country or region, not only the amount of time that has passed. @FedeGueli @aviczhl2 do you have recommendations for specific criteria to apply, taking countries or regions into account?

It would be awesome if every country had the resources to rapidly sequence an adequate sample of positive test cases, and the willingness and ability to rapidly release the sequences. But the reality is much more uneven.

[FedeGueli]

My criteria: 6 weeks with 0 sequences updated and the branch will be counted as dead. Is it too quickly?

6 weeks sounds reasonable to me for countries that have a shorter lag time from sample collection to release of sequences, like only a few weeks. I think @FedeGueli has explained in a different issue that unfortunately many countries, especially countries with fewer resources, may take more than a month to get sequences and release them publicly. So I think it depends on the country or region, not only the amount of time that has passed. @FedeGueli @aviczhl2 do you have recommendations for specific criteria to apply, taking countries or regions into account?

It would be awesome if every country had the resources to rapidly sequence an adequate sample of positive test cases, and the willingness and ability to rapidly release the sequences. But the reality is much more uneven.

I prefer to use a different criteria % of sequences uploaded in the last month with uploads vs total number of sequences of that lineage if it is 10% it is better closing it.

[AngieHinrichs]

I prefer to use a different criteria % of sequences uploaded in the last month with uploads vs total number of sequences of that lineage if it is 10% it is better closing it.

Thanks @FedeGueli! If I rephrase it this way, does this sound correct?

1. Determine the last month in which sequences on the branch were uploaded (not the month in which the samples were collected). This is the "last month with uploads." [How to do this -- by doing a GISAID query and looking at the Submission Date column?]
2. Find the number of sequences on the branch that were uploaded in that month.
3. Divide that number by the total number of sequences on the branch.
4. If the ratio is less than 10%, then comment on the issue, including all the numbers.

? Thanks. 🙂 Also, what if the last month in which sequences were uploaded was two months ago? Three months ago? Have you seen lag times longer than that?

[aviczhl2]

My criteria: 6 weeks with 0 sequences updated and the branch will be counted as dead. Is it too quickly?

6 weeks sounds reasonable to me for countries that have a shorter lag time from sample collection to release of sequences, like only a few weeks.

This criteria is not bad. However, I don't think he is actually using that criteria.

Take this one for example, many seqs are collected in 7/1-7/22 and uploaded on 7/30-8/12 to GISAID. Clearly that's within the 6 weeks range, but he still comments "dying" for this.

(Is it available to post GISAID info here? We can check GISAID by the query G22599C, T22928C, T17859C, T3172G, T3565C)

[FedeGueli]

I prefer to use a different criteria % of sequences uploaded in the last month with uploads vs total number of sequences of that lineage if it is 10% it is better closing it.

Thanks @FedeGueli! If I rephrase it this way, does this sound correct?

1. Determine the last month in which sequences on the branch were uploaded (not the month in which the samples were collected). This is the "last month with uploads." [How to do this -- by doing a GISAID query and looking at the Submission Date column?]
2. Find the number of sequences on the branch that were uploaded in that month.
3. Divide that number by the total number of sequences on the branch.
4. If the ratio is less than 10%, then comment on the issue, including all the numbers.

? Thanks. 🙂 Also, what if the last month in which sequences were uploaded was two months ago? Three months ago? Have you seen lag times longer than that?

yes plus or less that one, if the country where it emerged or it is prevalent didnt upload or uploaded very small numbers in the last three months we usually in the other repo tag that kind of lineages as emerged in an undersampled area and we keep them alive.

[AngieHinrichs]

Take this one for example, many seqs are collected in 7/1-7/22 and uploaded on 7/30-8/12 to GISAID. Clearly that's within the 6 weeks range, but he still comments "dying" for this.

Yes -- the original comment said "4 weeks" but then it was edited to say "6 weeks". I guess that means that DailyCovidCases formerly applied a 4-week cutoff, but now is thinking 6 weeks.

@DailyCovidCases in the future it would be more clear to explain the change in the comment instead of just changing a number. And does the process for accounting for a country's delay make sense to you?

[aviczhl2]

Take this one for example, many seqs are collected in 7/1-7/22 and uploaded on 7/30-8/12 to GISAID. Clearly that's within the 6 weeks range, but he still comments "dying" for this.

Yes -- the original comment said "4 weeks" but then it was edited to say "6 weeks". I guess that means that DailyCovidCases formerly applied a 4-week cutoff, but now is thinking 6 weeks.

@DailyCovidCases in the future it would be more clear to explain the change in the comment instead of just changing a number. And does the process for accounting for a country's delay make sense to you?

But 4 weeks is also not what he is actually using. This one has samples uploaded from 8/12(less than 1 week) and collected in 7/22(3 weeks ago)

I cannot understand any logic behind his comments, likely bugs from scripts. He also has record of reporting wrong number of seqs on various other issues.

[aviczhl2]

@AngieHinrichs I prefer temperoraily banning him unless he open source his code and we verify it bug-free. Without seeing his code it is impossible to find what is the actual bug.

[aviczhl2]

@corneliusroemer There seems more evidence of this one being a separate branch than JN.1.16.1

usher

[NkRMnZr]

the S:Q493E singlet now has a follow up with some accumulated spike mutations:

https://nextstrain.org/fetch/genome.ucsc.edu/trash/ct/subtreeAuspice51_genome_1a12c_d72dc0.json?label=id:node_11644668

[FedeGueli]

the S:Q493E singlet now has a follow up with some accumulated spike mutations:

https://nextstrain.org/fetch/genome.ucsc.edu/trash/ct/subtreeAuspice51_genome_1a12c_d72dc0.json?label=id:node_11644668

thx we will track it here .

[FedeGueli]

the 493E branch seems dead