Calculate unweighted unifrac with artifact API

[vittoriot]

Hi everyone,

I am working on a 16S sequencing data set from multiple bulk soils. I clustered at 99% and taxonomically classified with the latest Silva. I did normalization outside of qiime2 using CSS from metagenomeseq. I exported the log normalized table as tsv, transformed in BIOM and loaded back in QIIME2. I used unweighted unifrac to calculate pairwise distance between samples and plotted in a pcoa plot.
Thus far, the analysis was done with the command line version of qiime2. On the side I have been doing some plotting and data analysis with python using the log CSS normalized table from metagenomeseq.

I would like to continue my analysis using the qiime2 API but I am struggling to find resources to guide me in its use. I have seen the jupiter notebook example here.
However, it requires all the analysis to be done within the same environment. Specifically, can you guys give me an example of how to load an existing rooted tree from QIIME2 within python and run the diversity.methods.beta() function?

Hopefully this will make it more clear:

artifact_tab = Artifact.import_data(“FeatureTable[Frequency]”, otu_table)
unifrac_results=diversity.methods.beta(table=artifact_tab,phylogeny=artifact_tree,metric=‘unweighted_unifrac’)

How would I correclty provide “artifact_tree”? Should I import the tree in newick format [with something like ete3] and then load it as:

artifact_tree = Artifact.import_data(“NewickFormat”, newick_tree)

Thanks in advance for the assistance,
V

[ebolyen (Evan Bolyen)]

Hi @vittoriot!

@vittoriot

How would I correclty provide “artifact_tree”? Should I import the tree in newick format [with something like ete3] and then load it as:

artifact_tree = Artifact.import_data(“NewickFormat”, newick_tree)

Almost, just change your invocation to this:

Artifact.import_data("Phylogeny[Rooted]", path_to_newick, view_type="NewickFormat") 

Where view_type is the analogue of --source-format, but it can handle objects as well as formats, so this API is a bit more powerful.

In a perfect world, we would have a transformer from ete3 trees, we already use it as a dependency somewhere I believe, and in that case you could provide the object and omit the view_type entirely, but until then, the above should work.