nf-core / nf-core/magmap

Support eukaryotic metatranscriptomics via MMETSP transcriptome references

Open
#239 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Nextflow
Stars
12
Forks
6
Avg merge
1d 7h
Merged PRs (30d)
8

Description

Description of feature

Motivation: a real 92-sample project (mixed prokaryote/eukaryote communities, both metaG and metaT) saw very low mapping rates, because magmap only maps against prokaryotic genomes -- the eukaryotic fraction of the community (large, especially in the metaT) is invisible to it. magmap's architecture (align reads against a concatenated reference, then featureCounts against per-sequence features) doesn't inherently require the reference to be prokaryotic genomes -- it should work for eukaryotic transcriptome references too, treating each transcript set the way magmap currently treats a genome.

Why MMETSP, not MarFERReT

Both were considered. Checked both directly rather than assuming:

  • MMETSP (Marine Microbial Eukaryote Transcriptome Sequencing Project) distributes real assembled nucleotide contigs/CDS per sample (410 individual assemblies), alongside predicted proteins and annotation -- see the re-assembly project. This is nucleotide-level and maps onto magmap's existing --genomeinfo model (one row per organism, own fasta + optional gff) far more directly than a single combined file would.
  • MarFERReT (armbrustlab/marferret, paper) is protein-only by the time it's distributed -- the build pipeline ingests nucleotide and protein sequences but translates everything and the final Zenodo-distributed database is protein sequences. That doesn't work with magmap's BBMap-based nucleotide read mapping at all; it would need a protein-search tool (DIAMOND blastx-style) instead, a fundamentally different mapping paradigm, not a config change.

So: this issue is scoped to MMETSP. MarFERReT is explicitly out of scope -- if ever wanted, it'd be a separate, much bigger piece of work (a parallel protein-search pipeline), not an extension of this one.

Sourmash indexes

Sourmash sketch databases covering the MMETSP re-assembly (700+ marine eukaryotic transcriptomes) are available via OSF -- would let MMETSP entries be selected using the same Sourmash-based genome-selection machinery magmap already has for prokaryotic genomes, just pointing --indexes at an MMETSP-specific index. Verify the exact OSF link before relying on it -- found via search, not yet loaded and confirmed directly.

What would actually need building

  1. A new remote-source adapter. magmap's current remote-genome download (--remote_genome_sources, WGET_GENOME) is built specifically around NCBI's assembly_summary.txt format (accession + ftp_path, fetching <accno>*_genomic.fna.gz). MMETSP isn't NCBI-assembly-cataloged -- it's OSF/CAMERA-hosted with its own per-sample-ID layout. This needs a genuinely new fetch mechanism, not a param tweak.
  2. Bypass the domain-classification/Prokka-Bakta routing for MMETSP entries. The GTDB-based Bacteria/Archaea classification that drives --annotator routing is entirely prokaryote-specific and meaningless for MMETSP entries -- they'd need their own path that skips it.
  3. Annotation / GFF3. MMETSP ships its own per-sample annotation, but it's not confirmed to be plain GFF3-compatible with magmap's parsers -- may need converting, or may need to re-annotate from scratch with a proper gene caller. See the follow-up issue on eukaryotic gene-calling for this.
  4. GENOMES2ORFS extracts accessions from filenames via an NCBI-style regex (G.._[0-9.]+, matching GCA_.../GCF_...) -- MMETSP-style IDs (e.g. MMETSP0001) wouldn't match this. Another concrete spot needing generalization, not just a big-picture redesign.
  5. Verify BBMap alignment + featureCounts mechanics actually work sensibly once the input data is in the right shape -- a transcript is just a short "genome" with one main feature spanning most/all of it, which should fit the existing model, but worth confirming empirically once there's real test data.

Expected limitations, not blockers

  • metaG reads from intronic/intergenic regions (invisible to a transcriptome-only reference) will simply not map -- lower mapping rate, not a crash. How much lower varies a lot by taxon. This benefits metaT much more directly than metaG.

Related: see the follow-up issue on adding a eukaryotic gene caller (TransDecoder/MetaEuk), which item 3 above depends on.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the current WGET_GENOME remote-source path, the GTDB-based annotator routing, and GENOMES2ORFS accession extraction. Verify the MMETSP OSF index and annotation format, then test whether BBMap alignment and featureCounts handle transcriptome references. Done means MMETSP fetching, routing, identifiers, annotation handling, and mapping behavior work without relying on prokaryotic assumptions.

Written by the indexing model from the issue text.

Assessment

Domain
bioinformatics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.