I'd like to include more databases -- for eukaryot...
# metatdenovo
d
I'd like to include more databases -- for eukaryotes or any organism, GTDB covers prokaryotes well and is already available -- as options for
--diamond_dbs
. This can be in the form of instructions in the documentation (like https://nf-co.re/metatdenovo/1.1.1/docs/usage/#taxonomic-annotation-with-diamond), recipes for #C062H82UCRG or as files (a
.daa
together with NCBI-style taxonomy dumps
names.dmp
and
nodes.dmp
) we make available. I've discussed this with @m3hdad and @Adrià Auladell regarding EukProt, but that might need cleaning before we can proceed. Another option is MMETSP. Any comments, suggestions or data would be welcome!
a
I think both Eukprot and MMETSP will have some kind of contamination 😅 An alternative option could be to create the taxonomy using sourmash, what do you think about that? Using
sourmash gather
or the lca mode you can establish pretty confidently which guy is which. A faster option that has appeard not so long ago is sylph https://github.com/bluenote-1577/sylph But sorry, I am saying a lot of things without checking first exactly what you are creating as a taxonomic classifier
Now I have checked. Since its for the CDS, any system will work the same, it does not matter that much I think.
m
Hey you all, Quite by accident I noticed that EukProt3 might not be clean in a sense that accessions are assigned to the wrong taxid and I discussed it with @Daniel Lundin. From my point of view, nr with diamond does the job. The trade off is how confident we are about the database. One point remains however, those seqs that didn't get a hit on NCBI, are they novel or chimeric contigs? In case of metatranscriptomic, there isn't much to do but you might be able to filter those out by a TPM based filtering rule OR evigene as it is implemented in denovotranscript to get naturally valid CDS. happy to discuss further, cheers
d
Thanks both! @Adrià Auladell, what you bring up is alternative tools to Diamond and Eukulele, right? It would of course be good to have as resource-lean tools as possible in the pipeline, so at some point I'd be happy to include a third, probably kmer-based, tool. Note also #C031QH57DSS that uses an array of tools and anything that is present there could be adapted to be used in #C02FC6VFQG1 too.
👍 1
My question right now was more if you have any experience in cleaning upstream databases -- as well as which upstream databases would be worth looking into -- so we could make them available in #C02FC6VFQG1 (and possibly #C031QH57DSS as well) for any algorithm.
In a recent project we noticed that the NCBI RefSeq database we were using didn't assign even domain to a large proportion of ORFs and that at least half of those got an assignment either with Eukulele/MMETSP or Diamond/GTDB. This might be part of what you're observing @m3hdad with nr. My only guess is that highly divergent taxonomies (viruses as well as cellular domains) within the set of sequences considered by the LCA algorithm leads to this. In this case, I suppose using a lower value for
--diamond_top
would improve things. (I know it does shift sequences toward more specific ranks.)
m
well for my project specific use case I'm experimenting with gtax database, with kraken2 and centrifuge. Not sure if it'd all be a usefull source for you!
and my question is that, how confident are we that those sequences that didn't get a hit, are actually real sequences? :D
👀 1
d
Not at all, I suppose. However, the many ORFs that didn't get domain assigned in our project summed to quite a large proportion of TPMs so they don't seem like rare artifacts.
m
same here, I got about ~15% ORFs without rank -- unclassified, about half of them were real sequences.
d
Do you get them classified with your other tools? As I said, about half of the unclassified were classified with other tools in the pipeline in our case.
m
well in my case no, what ncbi failed to classify, was a hard fail for all tools. though I must say, my use case is different, I'm doing the assembly in denovotranscript and bringing evigene output in metatdenovo.
d
Interesting. We've mentioned meeting to discuss the overlap between the two pipelines! 🙂
m
I strongly believe in evigene process as it is cds centric to filter contigs that don't make sense in nature Yea, read the threads on that. I very much like the concept of doing an overassembly and cleaning after, what evigene recommends.
d
I haven't looked into evigene, sounds like I should.
Should be relatively easy to implement in #C02FC6VFQG1 if they used an nf-core module in #C04CWMEMWD7.
a
same here. First time I hear about it in fact, seems really cool.
m
yea, if you get a chance to look into evigene, i would be happy to hear your thoughts and discuss more. In case the metatranscript is coming from a eukaryote, depending on the lib prep, intron retention could also confuse transdecoder. I discussed it with new authors on denovotranscript and i believe evigene would also take care of that.
a
for how to clean upstream DB in my lab they are right now trying to create a new version of Eukprot (v4) and they will include some cleaning tools, yes. I could work as a bridge to discuss it further on what they are implementing exactly, but is still a work in progress
d
That would be great! (Personally, I do mostly prokaryotes, but I'm still keen to make sure the pipeline works well for eukaryotes.)
🎉 1
a
I have asked and Daniel Richter confirms what I thought: all of All of MMETSP is in EukProt, except for when species have been replaced by newer datasets.
> Quite by accident I noticed that EukProt3 might not be clean in a sense that accessions are assigned to the wrong taxid and I discussed it with @Daniel Lundin. for this part @m3hdad could you explain it more so I can try to pass it down?
m
Hi @Adrià Auladell I'll reply next week. Gotta wrap this week up :D