Add Dengue virus All serotypes dataset

[j23414]

Adding a serotype-level (all) dengue dataset, since it is functioning as expected.

Splitting this off of #203 since genotype-level datasets require further improvement to meet the desired standards.

https://clades.nextstrain.org/?dataset-server=gh:@add-serotype-level-dengue-dataset@&dataset-name=nextstrain/dengue/all

[j23414]

Thanks @ivan-aksamentov ! Fixed the README to resolve

• typo in name
• match dataset name in README to pathogen.json
• and plan to go forward with "Dengue virus All serotypes" ... "Dengue virus DENVx genotypes" <- I agree there should be consistency here : )

[ivan-aksamentov]

I noticed that in gene "E" at position 227 there is always (in example sequences at least) an amino acid mutation from * (stop codon) to either E, Q or S.

I am wondering why reference sequence has a stop codon in the middle of a gene (the gene is supposed to end here?), but none of the examples have it (so they keep going?). And then the genome annotation also disregards this fact and continues on to 495 amino acids total in the gene. Is this something that's expected? Perhaps specifics of this particular virus? (again, I have virtually no knowledge about it, I am sorry). Could there be an error in ref translation (i.e. incorrect frame - all genes seems to be annotated in frame 3 currently - if you switch to nuc sequence and look at the visualization of the annotation at the bottom of results table - it's completely flat) or something else?

[j23414]

why reference sequence has a stop codon in the middle of a gene

The reference in this case is the "Reconstructed_root_sequence_of_https_nextstrain_org_dengue/all/genome". I wonder if the reconstructed root of a tree with DENV1-DENV4 viruses which has varying length E genes results in an average inferred root E gene with a stop codon in the middle. I'm not sure...how to fix this. Open to other interpretations, or discussions.

The align rule for creating a nextclade dataset is here, the ancestral root was created in commit nextstrain/dengue@82007bc, and gff inferred in commit nextstrain/dengue@9a3f203

[j23414]

Just an update that my current hypothesis is that the average of DENV1-DENV4 nucleotide codons is creating a stop codon.

[huddlej]

Good catch on the stop codon in the reference, @ivan-aksamentov! I wouldn't expect the reference here to necessarily be a valid coding sequence, since it is an ancestral sequence reconstruction across four highly divergent virus serotypes. For the purposes of this "all serotypes" dataset, the main goal is to coarsely classify the input sequences as DENV1, 2, 3, 4, or none of the above. This dataset seems to accomplish that general goal with maybe one slight issue.

When I ran the example dengue sequences with this dataset, I noticed that most of the DENV2 samples got flagged as "mediocre" QC because of one "unexpected frameshift" and one of the DENV2 samples got a "bad" QC because of two unexpected frameshifts. I would bet that this frameshift is related to the use of an ancestral sequence as the reference and does not reflect an actual issue with the sequences, especially since it occurs in all of the sequences for a specific serotype.

I know @rneher recommended enabling the frameshifts QC in the original PR with genotype-level classification, but for coarser serotype-level classification where the amino acid sequence is less important than the nucleotide sequence I wonder whether we could disable this frameshift QC? Another option would be to add these few frameshifts from the example data to a list of known frameshifts (NS5:632-640, NS5:633-638, NS4B:14-20, NS4B:17-23).

Fixing this QC reporting issue could prevent people from accidentally throwing out valid classification of an entire serotype, if they have a QC filter in their workflows that only accepts "good" sequences.

[huddlej]

I just looked into this a bit more by aligning the sequences.fasta in this dataset to the reference.fasta with augur align and inspecting in AliView. The most common frameshift I mentioned above (NS5:632-640) appears in the screenshot below where there is a 5 nucleotide deletion in all of the DENV2 sequences relative to the reference and a 3 nucleotide deletion in the DENV3 sequences (coloring of triplets here is by amino acid codon).

When I aligned just the subset of DENV2 sequences, they don't have any frameshift at that position. There are some still some lower quality example sequences like OR389325_DENV2 (3168 Ns) and MZ312931_DENV2 (333 Ns), but it does seem like the frameshift you get from Nextclade alignment to this PR's dataset is a reference-specific issue.

[j23414]

Dropped the frameShift QC as suggested above, thanks all! I ran a quick check to make sure the dataset is classifying as expected:

I believe this is a reasonable dataset for the below:

main goal is to coarsely classify the input sequences as DENV1, 2, 3, 4,

And would provide the basis for future improvements if any. This is ready for review.

[huddlej]

This looks great, @j23414!

[rneher]

The DENV-2 sequences have a compensated frameshift. The 5 base deletion is followed by a two base insertion. It could be that with an even stronger gap penalty, these gaps would disappear.

One could 'rescue' the frameshift QC by adding this as a known frameshift.

[j23414]

Hello all, thanks for all the feedback and fixes! I may need more explicit guidance regarding this PR.

@rneher, could you please clarify if you are requesting the addition of known frameshifts somewhere in the pathogen.json file within this pull request, or if this is intended as potential future work to be addressed after the current pull request?

If the addition of known frameshifts is required, I have conducted a code search for "frameshift". Should I follow the same template as the one provided in the following link?

• https://github.com/search?q=repo%3Anextstrain%2Fnextclade_data%20frameshift&type=code

Alternatively, is there any documentation available that outlines the proper procedure for identifying and adding known frameshifts?

Guidance greatly appreciated on this matter to ensure I proceed correctly.

[ivan-aksamentov]

@j23414

Alternatively, is there any documentation available that outlines the proper procedure for identifying and adding known frameshifts?

Sorry, no clear docs, other than this small and outdated example, but, to clarify, you can add a frame shift to the list of ignored in qc.frameShifts.ignoredFrameShifts in this format:

nextclade_data/data/nextstrain/sars-cov-2/wuhan-hu-1/orfs/pathogen.json

Lines 57 to 63 in 03703e0

	{
	"codonRange": {
	"begin": 141,
	"end": 143
	},
	"cdsName": "S"
	},

and then it will be disregarded by the QC score. Note that the ranges here are 0-based half-open (right boundary is not included into the range), like in most programming languages, but for example in Web UI and TSV you will see 1-based closed ranges - the general convention in bioinformatics.

Not sure about identification though, and whether this is required or can be added later.

P.S. In this repo it is the most useful to search in the data/ directory where the sources are (the data_output/ is auto-generated), and SC2 datasets are one of the most fully-featured: repo:nextstrain/nextclade_data path:data/**/sars*/** frameshift

[j23414]

I added one frameshift to test the instructions (2e21708). Thanks @ivan-aksamentov!

But dropped it as I quickly realized that identifying known frameshifts would be a complex task... without documentation on the process.

[j23414]

Is there anything blocking this from being merged?

Also, who has merge-power in this PR? Based on commit history, mostly people on the Nextclade side?

[ivan-aksamentov]

@j23414

Is there anything blocking this from being merged?

I don't have any technical reasons to hold it. If scientists are happy, then we are ready to go.

Also, who has merge-power in this PR?

I think it is configured equally for core, so basically anyone. I answered on Slack with some more details about different branches and deploymens: https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1718427802913589?thread_ts=1716943598.732809&cid=C01LCTT7JNN

Based on commit history, mostly people on the Nextclade side?

That's because it's rarely that someone else contributes a dataset 😆

You are one of the early explorers of this process, so it might feel a little frustrating at times, sorry.