Add LASV GPC Nextclade dataset

[j23414]

Description of Proposed Changes

This PR introduces a draft GPC Nextclade dataset for the Lassa virus, enabling rapid lineage assignment and real-time mutation tracking. The dataset aims to support ongoing efforts to manage Lassa fever outbreaks by providing an efficient tool for identifying lineages, a critical step in understanding and mitigating the spread of this disease.

Copied below description from parts of #48 (comment)

The Lassa virus (LASV), the causative agent of Lassa fever(LF), is currently categorized into seven distinct lineages circulating in specific geographic regions (Garry, 2023). Lineages 1, 2, and 3 are primarily found in Nigeria, while lineages 4 and 5 are prevalent in Sierra Leone and Mali (Garry, 2023). These lineages not only circulate in different regions but also exhibit significant variations in immune response (Buck et al., 2022) and disease outcomes (Anderson et al., 2015). For instance, Anderson et al. demonstrated that the Sierra Leonean strain tends to be more fatal than the Nigerian strains.

In an effort to address this gap, we developed a tool for fast lineage assignment (Daodu et al., 2024). However, the tool is still limited in its capabilities, including the lack of a user-friendly interface. The success of the Nextclade dataset and rapid lineage assignment in managing the SARS-CoV-2 pandemic highlights the potential value of such resources for LASV control.

Building on the success of the Nextclade dataset for SARS-CoV-2, this PR incorporates lineage assignment from Daodu et al., 2024 (or more specifically these files) into a dedicated LASV GPC Nextclade dataset. This resource aims to fill gaps in LASV outbreak response tools, facilitating mutation tracking, lineage assignment, and broader outbreak management.

Draft Resources

• Scaffold tree: View scaffold tree
  This tree includes representative sequences from each lineage placed in a phylogenetic structure. New query sequences can be added and assigned to lineages based on their placement.

• Nextclade dataset: Test dataset
  This link allows users to explore and test the dataset features.

Related Issues(s)

• Add Nextclade dataset(s) #48

Checklist

• All checks pass

[j23414]

Thanks for pointing out the 60:X in the scaffold tree, I manually fixed the alignment in the following dataset:

• scaffold tree
• Nextclade dataset

[JoiRichi]

Were the sequences removed causing misalignment?

[j23414]

In this case, KM821977 aligned fine but was dropped since it had a run of n's in the nucleotide. I mostly wanted to avoid having a Nextclade scaffold tree with missing nucleotide information as I wasn't sure how that would influence query sequence placement.

[JoiRichi]

Did we pre-calculate the clock rate?

[j23414]

Yes, but I'm struggling to find the history of why 0.0006. I'll get back to you by end of next week.

[JoiRichi]

Thanks.

I tested the staged version of the LASV Nextclade with some data.

I am however worried that the pipeline may be deleting some nucleotides in
sequences - which I don't seem to have an answer for yet.

I have attached 3 images which show amino acid translation for OM735982.
Visualization of the alignment generated by Nextclade reveals that position
209 is missing. However, when this alignment was juxtaposed with another
alignment curated earlier, it revealed that a codon was removed by the
pipeline as there was supposed to be an 'N' in position 208 before the 'G'
in 209. This 'N' is present in the official translation on NCBI as shown in
the third image. This may mean that the codon was deleted without an
explanation (yet)

We may need to review how alignments are handled generally.

[j23414]

Thanks for raising the concern that the Nextclade alignment appeared to introduce gaps into sequences where a codon existed but was being removed and capturing the screenshot of the alignment! I'm documenting my corroborating exploration of the issue below. Will post some suggested paths forward.

[j23414]

To investigate this issue, I took the following steps:

1. Downloaded the sequence OM735982 from NCBI and imported it into Geneious.
2. Retrieved the same sequence from our Nextstrain-ingested data/gpc/sequences.fasta file:

nextstrain build phylogenetic data/gpc/sequences.fasta
smof grep OM735982 phylogenetic/data/gpc/sequences.fasta > OM.fasta # Changed header to 'OM735982_fasta'

3. Aligned the sequence against the dataset using Nextclade:

nextclade3 run \
  --input-dataset nextclade/dataset.zip \
  --output-all test_out \
  OM.fasta

4. Loaded all files into Geneious and performed a new alignment (confirming that the gap was present in the Nextclade alignment).
5. Loaded the Nextclade scaffold sequences into Geneious and performed another alignment.

• The gap appears at approximately amino acid position ~207 in the GPC gene.
• My hypothesis is that the codon CAA is being interpreted as a triplet indel compared to the scaffold tree alignment, which seems predominately GGG (or at least not CAA).

Potential Solutions

1. Add a CAA example sequence to the Nextclade scaffold tree to test if it resolves the indel issue.
   • Notes: This would be a straightforward solution if successful, but it raises questions about the need for frequent updates to the Nextclade dataset and how we flag new mutations.
2. Adjust the Nextclade alignment parameters by tweaking the alignment settings.
   • Notes: While this approach is more time-consuming, it could offer a more robust solution for handling novel mutations in Lassa sequences. The current parameters might inadvertently treat novel codons as deletions. However, relaxing the alignment parameters may lead to challenges with trying to replicate the results of codon-aware alignments.

[later edit]

3. Since the dataset seems to annotating the correct lineage calls, delay fixing the mutation calling to a separate PR. Perhaps try to include a disclaimer message on the mutation calling in the meanwhile.

[j23414]

How to explore Nextclade alignment parameters

For Option 2, I wrote up the default command with explicit nextclade parameters (based on nextclade help and diving into the code) to make it easier for others to explore the gappy behavior (and do their own exploration of Nextclade parameters) and how to fix it.

# What I'm inferring are the default values
nextclade3 run \
  --input-dataset nextclade/dataset.zip \
  --output-all test_out \
  OM735982.fasta \
  --min-length 100 \
  --penalty-gap-extend 0 \
  --penalty-gap-open 6 \
  --penalty-gap-open-in-frame 7 \
  --penalty-gap-open-out-of-frame 8 \
  --penalty-mismatch 1 \
  --score-match 3 \
  --retry-reverse-complement true \
  --no-translate-past-stop false \
  --gap-alignment-side left \
  --excess-bandwidth 9 \
  --terminal-bandwidth 50 \
  --allowed-mismatches 8 \
  --min-match-length 40 \
  --max-alignment-attempts 3 \
  --include-reference true \
  --include-nearest-node-info true 

# Still contains the gap
less test_out/nextclade.aligned.fasta

[later edit] I was trying to find out why the default values are not listed in the nextclade run -h and we need to dig into the code, and found closed issue: nextstrain/nextclade#1253

Looks like it's due to a dependency on clap to generate the cli help message.

[j23414]

Pivot away from option 2 (adjusting Nextclade params) to option 1 (adding CAA samples to the scaffold tree)

I'm not finding a set of Nextclade parameters to rescue the CAA deletion. If someone else does and can demonstrate that it works for OM735982, please post the command here!

I'm pivoting to try option 1 of adding a few CAA samples to the scaffold tree.