Hi, I'm using phylo-RPCA-with-taxonomy in Gemelli (@cmartino) and have encountered some off behavior in the phylo-taxonomy output. After running the function, a number of tree tips (ASVs) have been reassigned to different phyla, and (strangely) all Proteobacteria have been assigned to a single genus (Rhodanobacter)! (see differences in taxonomy vs phylo-taxonomy visualizations and rooted-tree vs. phylo-rooted tree Empress plots.)
The data I'm working with are ASVs output from DADA2, with taxonomies assigned with a naive Bayesian classifier trained on Silva138 V3-V4.
I'm presuming this reclassification is a result of the tax2Tree decoration step that Gemelli uses, and I'd expect some minor changes to taxonomy occur during this, but jumping phyla or reclassifying a whole phylum as a single genus is far beyond what I expected. Is this occurrence to be expected, or have I triggered something unusual?
Thanks in advance,
-Nathan Stewart
Thanks for using phylo-RPCA and for reporting this issue. I agree, this is concerning. I ran through your example and was able to reproduce the results. After digging into the individual steps it seems the issue is in tax2tree which phylo-RPCA is wrapping to get the LCAs. I am going to bring @wasade here for help because I am not as familiar with the inner workings of tax2tree. @wasade is this some unexpected behavior by t2t?
@cmartino, Kalen Cantrell, and I are discussing this out of band. If I do a decoration directly with tax2tree, using effectively the same input data, I get results that on the surface seem reasonably consistent with the input taxonomy. See below for which ASVs are Rhodanobacter in the input (df) and the tax2tree observed (obs). We are working on figuring out the source of the discrepancy.
@wasade If possible, would you mind sharing how ran this? I am encountering some difficulties running the t2t decoration directly myself.
Thanks,
-Nathan
Sorry for the delay, I've been offline a few days.
It's not straight forward. The QIIME 2 taxonomy output is not uniform, where some lineages are specified to s__ but not all are. tax2tree requires lineages are fully specified so there is some manual normalization that is needed. I think that was the main crux.
I would prefer a solution within Gemelli, rather than suggesting a hack. Let's wait to hear back from the Gemelli developers, and if the fix is convoluted or likely to take a while to implement, then I'll propose a manual workaround. Sound reasonable?
@wasade
No worries.
Sure thing, having a solution within Gemelli would be preferable. Can I run my t2t attempt by you though to see if there's anything obviously incorrect?
Exported taxonomy.qza to a tsv file.
Used the code suggested by @mortonjthere to make the taxonomy readable by t2t. This seems to work, as in the output (gg2-t2t_consistency.tsv (115.0 KB)) all ASVs are specified down to s__, even though some levels are empty.
The decoration will run, but it will throw a bunch of OBSERVED/EXPECTED warnings, e.g: AFFECTED: 2 EXAMPLE: ASV730 OBSERVED: ['p__Patescibacteria', 'c__Saccharimonadia', 'o__UBA4664', 'f__UBA4664', 'g__UBA4664'] EXPECTED: ['d__Bacteria', 'p__Patescibacteria', 'c__Saccharimonadia', 'o__UBA4664', 'f__UBA4664', 'g__UBA4664']
The output tree (gg2_t2t_out.txt (29.1 KB)) and consensus strings (gg2_t2t_out-consensus-strings.txt (42.2 KB)) only specify d__bacteria and leave all other levels blank, though F-measures are produced for all taxa at all levels (gg2_t2t_out-fmeasures.txt (8.0 KB)).
Thanks for your time, and any help is greatly appreciated!
-Nathan
Oh right. That. When I was checking this, I hit that bug too and just realized I forgot to open an issue about it -- it's been a hectic couple of weeks. An issue is now open.
That consistency check was added in when we were working on Greengenes2 as a means truncate lineages that were incompatible with the input taxonomy. This can arise if the phylogeny and input taxonomy disagree substantially in parts of the tree, and is a safety to avoid producing something definitely incorrect. We designed the code to around two domain trees. In this case, the tree does not span two domains, so the domain label ends up placed on the root node. That violates an incorrect assumption (i.e., bug) the code currently makes (see here) where it assumes the root is unlabeled. As a result, the observed labels lack Bacteria, therefore creating a consistency issue, resulting in truncation, and a tree that doesn't have anything interesting when written.
If you're feeling adventurous, you could either hack the t2t code to remove the consistency check (ie comment this out), or issue a fix and send a PR ( ).
Hi @NathanStewart thank you so much for your patience, we are still working behind the scenes on a fix for this. I opened an issue on this GitHub here. Stay tuned and thank you again for reporting this!!
@wasade Thank you! I commented out that section on a t2t install and it worked great, with a much more reasonable output. No guarantees I can issue a fix; my python coding is mediocre at best...
@cmartino No problem, and thank you for working on it!
).