# Possible Analysis Pipeline for Ion Torrent 16S Metagenomics Kit Data in QIIME2?

**URL:** https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476
**Category:** User Support
**Tags:** best-of-the-forum
**Created:** [February 5, 2020, 12:53am UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476 "2020-02-05T00:53:06Z")
**Posts on this page:** 20
**Page:** 2

<div class="post-metadata">

### Author: ![fulbag](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/f/958977/32.png) [@fulbag](https://forum.qiime2.org/u/fulbag)
#### Post date: [March 8, 2020, 1:27pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/24 "2020-03-08T13:27:30Z")

</div>

> [@Lauren](#):
>
> just to clarify, these are the fastq files that you get directly from your sequencer / server - not out of Ion Reporter

Thank you for correcting me - 😊,

> [@Lauren](#):
>
> And those are exactly the files that Carli is using as input in her first post in this thread:

As above, 😊

So, according to your and @Nicholas_Bokulich comments, the fastq files are 'useless'... unless we may decipher how these .fastq consensus sequences are assembled by the PGM server.  
From my previous experience on the T cell receptor V-D-J region (on the alpha and beta chains) sequencing (Sanger's sequencing - years ago), the consensus was (manually) built by placing the V-D-J sequences within the conserved domains.  
Wrongly, I was assuming that here the .fastq consensus were built in a similar way, but now I realize that this is not true...

> [@Lauren](#):
>
> we would be able to at least pick sequences from one variable region to analyze our data.

So, basically it is not (yet) possible to extract from these .fastq files a single V region for the pipeline analysis - since primer sequences are not present.  
Correct? 🙄  
Thanks.

---

<div class="post-metadata">

### Author: ![rparadiso](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/r/4af34b/32.png) [@rparadiso](https://forum.qiime2.org/u/rparadiso)
#### Post date: [March 24, 2020, 12:18am UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/25 "2020-03-24T00:18:44Z")

</div>

> [@fulbag](#):
>
> So, basically it is not (yet) possible to extract from these .fastq files a single V region for the pipeline analysis - since primer sequences are not present.  
> Correct? 🙄  
> Thanks.

Really I tried to extract from my reads the v3 and v4 regions. I used some primers that I suppose to be used in the kit and the analysis work. The only problem was that a big part of you sequence are lose in the bioinformatic analysis

---

<div class="post-metadata">

### Author: ![Jen\_S](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/j/cdc98d/32.png) [@Jen\_S](https://forum.qiime2.org/u/Jen_S)
#### Post date: [March 25, 2020, 2:52pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/26 "2020-03-25T14:52:16Z")

</div>

Hi @Lauren and @cjone228,

@KMaki and I are working with the same data as you and wanted to ask you all after running dada2, what percentages did you get from the denoising output in the variable from the denoising stats qzv:  
"Percent of input passed filter"

We see that the nice Parkinson's tutorial has an average of percent of about 95%. Our Ion Torrent specific data has an average about .2% to our best which is about 30% across all runs. What did you all see here after this step?

Thank you!  
Jen

---

<div class="post-metadata">

### Author: ![colinbrislawn](https://forum.qiime2.org/user_avatar/forum.qiime2.org/colinbrislawn/32/6221_2.png) [@colinbrislawn](https://forum.qiime2.org/u/colinbrislawn)
#### Post date: [March 25, 2020, 3:03pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/27 "2020-03-25T15:03:24Z")

</div>

> [@Jen\_S](#):
>
> Our Ion Torrent specific data has an average about .2% to our best which is about 30% across all runs.

Ouch!

Try increasing the trimming parameters to remove low quality starting and ending positions.

Also, just to check, are you using [denoise-pyro](https://docs.qiime2.org/2020.2/plugins/available/dada2/denoise-pyro/)? The PD-mouse tutorial uses Illumina data, which has different defaults than pyro data like Ion Torrent.

Colin

---

<div class="post-metadata">

### Author: ![cjone228](https://forum.qiime2.org/user_avatar/forum.qiime2.org/cjone228/32/5613_2.png) [@cjone228](https://forum.qiime2.org/u/cjone228)
#### Post date: [March 25, 2020, 6:23pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/28 "2020-03-25T18:23:54Z")

</div>

> [@Jen\_S](#):
>
> Our Ion Torrent specific data has an average about .2% to our best which is about 30% across all runs. What did you all see here after this step?

Hi Jen! Sorry to hear you are having this issue - I just finished the DADA2 step for my samples, which span 4 separate chips, and for each of them it seems as though typically 70-80% of the reads pass the filter. This was true for @Lauren's samples too.

Here is an example of our code:

```
qiime dada2 denoise-pyro \
  --p-trim-left 15 \
  --p-trunc-len 0 \
  --i-demultiplexed-seqs ~/work/Carli/Chip3/Chip3_demux.qza \
  --o-table ~/work/Carli/Chip3/Chip3_table.qza \
  --o-representative-sequences ~/work/Carli/Chip3/Chip3_rep_seqs.qza \
  --o-denoising-stats ~/work/Carli/Chip3/Chip3_denoising_stats.qza \
  --verbose

```

I hope this helps!  
Carli

---

<div class="post-metadata">

### Author: ![rparadiso](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/r/4af34b/32.png) [@rparadiso](https://forum.qiime2.org/u/rparadiso)
#### Post date: [March 26, 2020, 10:53am UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/29 "2020-03-26T10:53:56Z")

</div>

Hi I try to use your pipeline for the analysis of my data, but I have a problem with the importing.

qiime tools import  
--type 'SampleData[SequencesWithQuality]'  
--input-path /Users/rparadiso/Documents/Progetti/Microbiota\_orecchio\_cane/QIIME\_analysis/FastQ/manifest\_1\_15.csv  
--output-path demux\_1\_15.qza  
--input-format SingleEndFastqManifestPhred33

This is the error message:  
There was a problem importing /Users/rparadiso/Documents/Progetti/Microbiota\_orecchio\_cane/QIIME\_analysis/FastQ/manifest\_1\_15.csv:

/Users/rparadiso/Documents/Progetti/Microbiota\_orecchio\_cane/QIIME\_analysis/FastQ/manifest\_1\_15.csv is not a(n) SingleEndFastqManifestPhred33 file:

Line 3 has 1 cells (['/Users/rparadiso/Documents/Progetti/Microbiota\_orecchio\_cane/QIIME\_analysis/FastQ/1\_15/1\_DX.fastq.gz']), expected 3.

Can you help me?

Thanks

---

<div class="post-metadata">

### Author: ![cjone228](https://forum.qiime2.org/user_avatar/forum.qiime2.org/cjone228/32/5613_2.png) [@cjone228](https://forum.qiime2.org/u/cjone228)
#### Post date: [March 26, 2020, 11:41am UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/30 "2020-03-26T11:41:19Z")

</div>

Hi Rubina,

I think the problem is that your manifest file is a .csv file and not a .tsv file! Try making it a .tsv file and hopefully that will work.

Best,  
Carli

---

<div class="post-metadata">

### Author: ![Lauren](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/l/b4bc9f/32.png) [@Lauren](https://forum.qiime2.org/u/Lauren)
#### Post date: [April 3, 2020, 6:17pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/31 "2020-04-03T18:17:40Z")

</div>

Hi Everyone!

@cjone228 and I want to clarify this point - we just realized that using the the full length sklearn classifier is _not_ advised because the pre-trained sklearn classifier doesn't do well with mixed-orientation reads (see [post](https://forum.qiime2.org/t/classifier-for-ion-torrent-data/3675)). We just had the problem where we were only getting ~60-70% classification with both Silva and GG and realized that mixed orientation reads are likely the culprit. Thus, we will try to move forward with classify-consensus-vsearch. Just found this [post](https://forum.qiime2.org/t/sequence-extraction-and-classifier-training-for-ion-torrent-data/14097) - super helpful! 🥳 🤩 😆 @KMaki have you gotten vsearch consensus classifier to work? If so, do you mind sharing your final code? 🙏

Investigation of this hurdle brought up another question: do we need to deal with our mixed orientation reads prior to the taxonomy steps? (Just a reminder that IT produces single end reads, but each sample includes reads from 12 different pooled amplicons: 6F primers and 6R primers.) @Jen_S [posted](https://forum.qiime2.org/t/reverse-complement-trimmed-reads/13673) on this topic and @Nicholas_Bokulich recommended separating out F from R reads prior to denoising, denoising separately, and then merging. Is this something we should do? Could mixed oriented reads be part of why only ~70% of our sequences are passing the dada2 filter? (see @cjone228 and @Jen_S discussion on that below).

Thanks much!  
Lauren :qiime2:

---

<div class="post-metadata">

### Author: ![Nicholas\_Bokulich](https://forum.qiime2.org/user_avatar/forum.qiime2.org/nicholas_bokulich/32/19937_2.png) [@Nicholas\_Bokulich](https://forum.qiime2.org/u/Nicholas_Bokulich)
#### Post date: [April 3, 2020, 7:01pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/32 "2020-04-03T19:01:47Z")

</div>

Hi @Lauren,

> [@Lauren](#):
>
> do we need to deal with our mixed orientation reads prior to the taxonomy steps?

Ideally yes, since having mixed-orientation reads will inflate (particularly alpha) diversity estimates, since each true ASV is being counted twice (once for each orientation). OTU clustering may be a way to correct this post-dada2, but I have not looked into it yet.

> [@Lauren](#):
>
> @Nicholas_Bokulich recommended separating out F from R reads prior to denoising, denoising separately, and then merging.

Just to clarify, this is if the F/R reads are being re-oriented as @Jen_S was doing... because I think dada2 would probably explode if it is fed re-oriented reads, since the quality profiles would be reversed as well. If you are sorting out orientation issues post-dada2, you don't need to separate for denoising.

> [@Lauren](#):
>
> Could mixed oriented reads be part of why only ~70% of our sequences are passing the dada2 filter?

No, probably not. That's more likely related to trimming/truncation parameters and quality profile more generally.

---

<div class="post-metadata">

### Author: ![KMaki](https://forum.qiime2.org/user_avatar/forum.qiime2.org/kmaki/32/7740_2.png) [@KMaki](https://forum.qiime2.org/u/KMaki)
#### Post date: [April 3, 2020, 9:58pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/33 "2020-04-03T21:58:30Z")

</div>

Hi @Lauren !

I am happy you found the post helpful! 🥰 I am going to do my best to answer your questions, but will do so in reverse to line up with workflow.

The most effective adjustment that I made in DADA2 to increase the amount of sequences that passed denoising was decreasing my trun length. Decreasing the truncation length from 250 bp to 150 bp increased the amount of sequences that passed through DADA2 filtering from ~2% up to percentages in the 80s. This was not true across all areas but helped greatly. I saw that you don’t truncate so it may be worthwhile to try seeing if truncating at 250 or 150 improves your filtering percentages without sacrificing accuracy (I think I remember reading you have some mock samples so you can evaluate this). We also trim at 15 bp and use the DADA2 –pyro option.

VSEARCH has worked well for us so far! We are still doing the comparisons to see how it lines up to our old workflow but so far we have been happy with the result.

**The code for vsearch classification is below:**  
qiime feature-classifier classify-consensus-vsearch   
--i-query merged\_rep\_seqs\_pyro\_trun150.qza \ #This is rep seqs artifact  
that comes from DADA2 output after merging all of the runs together  
(if applicable)  
--i-reference-reads gg\_99\_otus.qza \ #This is the green genes 99%  
OTUs that we converted to an artifact (Code at bottom)  
--i-reference-taxonomy gg\_ref-taxonomy.qza \ #Reference tax from  
Greengenes also converted to qiime Artifact (code below)  
--o-classification vsearch\_gg\_classification\_trun150.qza #output

**Qiime visualization:**  
qiime metadata tabulate   
--m-input-file vsearch\_gg\_classification\_trun150.qza   
--o-visualization vsearch\_gg\_classification\_trun150.qzv

**Code to import Greengenes.fasta and taxonomy.txt into Qiime2 artifacts**  
Note you get the Greengenes data from Qiime2 data resources [here](https://docs.qiime2.org/2020.2/data-resources/#taxonomy-classifiers-for-use-with-q2-feature-classifier)

qiime tools import   
--type 'FeatureData[Sequence]'   
--input-path 99\_otus.fasta   
--output-path gg\_99\_otus.qza

qiime tools import   
--type 'FeatureData[Taxonomy]'   
--input-format HeaderlessTSVTaxonomyFormat   
--input-path 99\_otu\_taxonomy.txt   
--output-path ref-taxonomy.qza

I hope this helps! Please let me know if you have any other questions

Sincerely,  
Katherine 😊

---

<div class="post-metadata">

### Author: ![Nicholas\_Bokulich](https://forum.qiime2.org/user_avatar/forum.qiime2.org/nicholas_bokulich/32/19937_2.png) [@Nicholas\_Bokulich](https://forum.qiime2.org/u/Nicholas_Bokulich)
#### Post date: [April 3, 2020, 11:53pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/34 "2020-04-03T23:53:54Z")

</div>

Thanks @KMaki!

It's about time we get a QIIME 2 tutorial for ion torrent sequencing put together, per the title of this topic. Maybe everyone who has posted to this topic should team up to write a tutorial that we can post in the "community tutorials" section of the forum (and eventually the QIIME 2 library)... anyone interested? It takes a village to write a tutorial... 🏘

---

<div class="post-metadata">

### Author: ![KMaki](https://forum.qiime2.org/user_avatar/forum.qiime2.org/kmaki/32/7740_2.png) [@KMaki](https://forum.qiime2.org/u/KMaki)
#### Post date: [April 7, 2020, 2:04pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/35 "2020-04-07T14:04:20Z")

</div>

@Jen_S and I are definitely interested in putting together a tutorial. We are currently trying to contact IonTorrent to see if there is a way to extract V regions with a plugin or some other way to preserve their intellectual property while working with the QIIME2 workflow. This will determine how we arrange the future workflow so based on what plays out we can start working on the IonTorrent analysis tutorial.

---

<div class="post-metadata">

### Author: ![KMaki](https://forum.qiime2.org/user_avatar/forum.qiime2.org/kmaki/32/7740_2.png) [@KMaki](https://forum.qiime2.org/u/KMaki)
#### Post date: [April 8, 2020, 2:02pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/36 "2020-04-08T14:02:25Z")

</div>

Hey @Nicholas_Bokulich and @colinbrislawn

I have a follow up question about my vsearch taxonomy classifier. One of my regions has a higher percentage of unclassified taxa than the other and I'm thinking I could potentially tweak some of the vsearch settings in the "qiime feature-classifier classify-consensus-vsearch" command.

I am currently using the default parameters (as I have in my code in my response to @Lauren

I am curious if you have any suggestions for parameters to adjust as a starting point to try and improve this unclassified tax %?

My DADA2 stats in this region are pretty good and nothing changed when I increased the truncation length of the segment pulled from greengenes so I think tweaking the vsearch parameters would be a good next testing point. 🤔

Appreciate any thoughts/suggestions you may have, thank you!  
Katherine

---

<div class="post-metadata">

### Author: ![Lauren](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/l/b4bc9f/32.png) [@Lauren](https://forum.qiime2.org/u/Lauren)
#### Post date: [April 8, 2020, 2:27pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/37 "2020-04-08T14:27:46Z")

</div>

Hi @Nicholas_Bokulich and @KMaki,

Sorry for my delayed response - thank you both very much for your input! 👍

> [@Lauren](#):
>
> > [@Lauren](#):
> >
> > do we need to deal with our mixed orientation reads prior to the taxonomy steps?
> 
> Ideally yes, since having mixed-orientation reads will inflate (particularly alpha) diversity estimates, since each true ASV is being counted twice (once for each orientation).

This makes sense - @cjone228 and I are completely new to bioinformatics so we are learning along the way. It didn't occur to us until last week that we were importing mixed reads using SingleEndFastqManifestPhred33V2. We now see on the Qiime2 Docs importing data page that "In this variant of the fastq manifest format, the read directions must all either be forward or reverse."

I think that it makes sense for us to re-orient our reads as @Jen_S did because approximately half of our reads are F and half R.

@KMaki, your reply post on VSEARCH is very clear (thank you!) - however I think @cjone228 and I need to take a step back and work on re-doing the initial steps before we get to this point.

@Nicholas_Bokulich, I would be happy to contribute to a tutorial, however I need to figure out what I am doing first! 😆

Now I have a few new discoveries / questions that go back to late February when I was going through output files from Ion Reporter with @colinbrislawn:  
It occurred to me that I only listed a few of the files that IR spits out. Turns out it also spits out the following list:

 ![Screen Shot 2020-04-08 at 9.49.35 AM](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/5/571e9a256dde13a546ffce68e8c5e20922fec780.png)

I see that IR is using Qiime v 1.9.1, so is it possible for me to convert some of these files into Qiime2 compatible files and use them? My concern is that IR does everything through it's own server, so we wouldn't have access to any of the intermediate files (if there are any). Also, I am happy to open more of the folders and show you what is in them if that is helpful.

I see that I have some taxonomy .biom files, so yesterday I was trying to convert the OTU\_family.biom file into a Qiime2 .qza file. I found this [post](https://forum.qiime2.org/t/workflow-when-importing-biom-table-without-sequences/12127/3) and attempted to follow the instructions (see screenshot below)

 ![Screen Shot 2020-04-08 at 10.10.31 AM](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/b/b342bcddfd3bd9d0ec85ff15cb00a1c3e1b8be40.png)  
I picked --type FeatureData [Taxonomy] because is doesn't look like my file has any sequences in it and I picked --input-format BIOMV210Format because my file states "BIOM-Format 2.1.7" and it was made with Qiime v 1.9.1 (see .biom contents in screenshot below)  
 ![Screen Shot 2020-04-08 at 10.14.13 AM](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/8/854e7dc867154a0071c06dd0782217ab7aae8ee5.png)  
As always, if anyone has any insight I greatly appreciate it!  
Take care,  
Lauren

---

<div class="post-metadata">

### Author: ![thermokarst](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/t/8e7dd6/32.png) [@thermokarst](https://forum.qiime2.org/u/thermokarst)
#### Post date: [April 8, 2020, 2:43pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/38 "2020-04-08T14:43:18Z")

</div>

> [@Lauren](#):
>
> I picked --input-format BIOMV210Format because my file states “BIOM-Format 2.1.7” and it was made with Qiime v 1.9.1 (see .biom contents in screenshot below)

Hey @Lauren - good sleuthing, but I think that might be a red herring - the _original_ file was generated using biom 2.1.7, but if you look one line up you'll see that the _current_ format is biom 1.0.0.

The post you linked to for importing taxonomy data from a biom table only works with biom 2 files - all you need to do is convert this biom 1 file to a biom 2 file using the biom CLI tool:

[http://biom-format.org/documentation/biom\_conversion.html](http://biom-format.org/documentation/biom_conversion.html)

Once converted you might be able to import as taxonomy, although based on the screenshot, I'm not 100% sure that'll work, because that special import invocation expects the taxonomy to be stored as metadata in the biom table, rather than the IDs themselves.

---

<div class="post-metadata">

### Author: ![Lauren](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/l/b4bc9f/32.png) [@Lauren](https://forum.qiime2.org/u/Lauren)
#### Post date: [April 8, 2020, 3:01pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/39 "2020-04-08T15:01:44Z")

</div>

Thanks @thermokarst!

> [@thermokarst](#):
>
> the _original_ file was generated using biom 2.1.7, but if you look one line up you’ll see that the _current_ format is biom 1.0.0.

I wondered about that... so thanks for clarifying!

> [@thermokarst](#):
>
> all you need to do is convert this biom 1 file to a biom 2 file using the biom CLI tool:

Sounds good- will do 👍

> [@thermokarst](#):
>
> Once converted you might be able to import as taxonomy, although based on the screenshot, I’m not 100% sure that’ll work, because that special import invocation expects the taxonomy to be stored as metadata in the biom table, rather than the IDs themselves.

Sigh... ok - It is worth a try, but I won't expect too much based on your insight. 😒

Thanks again!  
Lauren

---

<div class="post-metadata">

### Author: ![Nicholas\_Bokulich](https://forum.qiime2.org/user_avatar/forum.qiime2.org/nicholas_bokulich/32/19937_2.png) [@Nicholas\_Bokulich](https://forum.qiime2.org/u/Nicholas_Bokulich)
#### Post date: [April 8, 2020, 4:17pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/40 "2020-04-08T16:17:22Z")

</div>

> [@KMaki](#):
>
> I am curious if you have any suggestions for parameters to adjust as a starting point to try and improve this unclassified tax %?

Unclassified taxa can occur for a few reasons with the vsearch-based classifier:

1. there really is no good match.
  1. Seems unlikely if this is region-specific, but that could occur if the reference sequences have a jumble of different regions covered (e.g., different primers were used for sequencing those reference sequences). It looks like you are using Greengenes? So that is probably not the case, either.
  2. Can occur if `--p-perc-identity` is set too high... but the default is really low, so that's probably not the issue.
  3. Can also occur if reads are in the wrong orientation, but the default is to check both orientations, so not the issue here.

2. there is more than one match at the basal taxonomic level (kingdom in the case of greengenes) above the consensus threshold. So theoretically you may be hitting both bacteria and archaea, leading to "unclassified" (because reliable classification cannot be achieved at even the basal level).
  1. Since your query sequences (and possibly also reference sequences) are mixed orientations and you are searching in both directions, you could be picking up hits in both directions (only one of which would be valid!). I recommend increasing `--p-perc-identity` a little bit to see what happens, also test out the `max-hits` and `top-hits-only` settings to see how they impact your results. If you suddenly get much better results (without setting max-hits or max-accepts to 1!!!) then you've struck gold.

> [@KMaki](#):
>
> nothing changed when I increased the truncation length of the segment pulled from greengenes

Could you clarify? Are you using extract-reads on the reference sequences? If so, don't use `trunc-len` on those reads (since your query seqs are in mixed orientations they can hit at either end of that read)

> [@Lauren](#):
>
> I see that IR is using Qiime v 1.9.1, so is it possible for me to convert some of these files into Qiime2 compatible files and use them?

Yes that works too, but based on @thermokarst's notes, it looks like the biom tables you have are already collapsed on taxonomy so may not be enormously helpful.

> [@KMaki](#):
>
> @Jen_S and I are definitely interested in putting together a tutorial.

> [@Lauren](#):
>
> @Nicholas_Bokulich, I would be happy to contribute to a tutorial, however I need to figure out what I am doing first! 😆

🥳  
Let's circle back to this — I think the prospect of building a community tutorial (especially one written by different research groups who are bringing different perspectives to the table) is really exciting.

Good luck to you both! Let us know if you have any more questions.

---

<div class="post-metadata">

### Author: ![KMaki](https://forum.qiime2.org/user_avatar/forum.qiime2.org/kmaki/32/7740_2.png) [@KMaki](https://forum.qiime2.org/u/KMaki)
#### Post date: [April 8, 2020, 5:54pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/41 "2020-04-08T17:54:04Z")

</div>

Thanks so much for the input, I will try to vsearch parameters and report back

> [@KMaki](#):
>
> nothing changed when I increased the truncation length of the segment pulled from greengenes

> [@Nicholas\_Bokulich](#):
>
> Could you clarify? Are you using extract-reads on the reference sequences? If so, don’t use `trunc-len` on those reads (since your query seqs are in mixed orientations they can hit at either end of that read)

As you guessed, currently we are pulling out segments from the greengenes "99\_otus" artifact we import into QIIME2 corresponding to our desired V regions using "qiime feature-classifier extract-reads". Would you mind expanding on your statement:

> [@Nicholas\_Bokulich](#):
>
> (since your query seqs are in mixed orientations they can hit at either end of that read)

Do you mean since we have mixed orientations there is a concern that the greengenes sequences needed to classify taxa using vsearch may be missed if we truncate?

Should be not using the trun-len at all for the extract reads command ?  
Example code below (X's would be the primer sequences)

qiime feature-classifier extract-reads   
--i-sequences gg\_99\_otus.qza   
--p-f-primer XXXXXXX  
--p-r-primer XXXXXXX   
--p-trunc-len 250 \ #Remove this?  
--p-min-length 100 \ #Keep this?  
--p-max-length 400 \ #Also keep this?  
--o-reads v2\_gg\_ref-seqs.qza

I got pretty good classification percentages in my other region but maybe this was just luck?

Thanks so much!

> [@Nicholas\_Bokulich](#):
>
> 🥳  
> Let’s circle back to this — I think the prospect of building a community tutorial (especially one written by different research groups who are bringing different perspectives to the table) is really exciting.

Strongly agree with the above!!! 🤩 👩‍💻

---

<div class="post-metadata">

### Author: ![Nicholas\_Bokulich](https://forum.qiime2.org/user_avatar/forum.qiime2.org/nicholas_bokulich/32/19937_2.png) [@Nicholas\_Bokulich](https://forum.qiime2.org/u/Nicholas_Bokulich)
#### Post date: [April 8, 2020, 6:37pm UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/42 "2020-04-08T18:37:53Z")

</div>

> [@KMaki](#):
>
> Would you mind expanding on your statement:
> 
> > [@Nicholas\_Bokulich](#):
> >
> > (since your query seqs are in mixed orientations they can hit at either end of that read)
> 
> Do you mean since we have mixed orientations there is a concern that the greengenes sequences needed to classify taxa using vsearch may be missed if we truncate?

Yes. Normally (when read orientation is consistent) truncation can be used with extract-reads to match the exact same site and length as in the query. For example:

**imaginary query** :  
**ACGTACGTACGTACGTACGTACGTACGT** cccccccccccccccc

**imaginary reference** :  
ggggggggggggggg **ACGTACGTACGTACGTACGTACGTACGT** ccccccccccccccccgggggggggggggg

(lowercase "g"s == primer sites)  
(lowercase "c"s == part of amplicon sequence that corresponds to region that was truncated from query by dada2)  
(bold == part of amplicon that appears in truncated forward reads/reference sequences)

Using extract-reads on that reference would yield an exact match (or in real life just match the same region/conditions so enable exact or similar matches between query and ref):  
truncated query: **ACGTACGTACGTACGTACGTACGTACGT**  
truncated refseq: **ACGTACGTACGTACGTACGTACGTACGT**

However, when orientations are mixed, you don't know which end of the amplicon your query sequences are on... you will have a mixture of:

**ACGTACGTACGTACGTACGTACGTACGT** cccccccccccccccc

and its reverse complement:

ggggggggggggggg **ACGTACGTACGTACGTACGTACGTACGT**

Which truncated (on 3' end of each read) will yield:

**ACGTACGTACGTACGTACGTACGTACGT**

and

ggggggggggggggg **ACGTACGTACGTAC**

So you are covering different parts of the complete amplicon. Hence, the reference sequences should be untruncated to cover the full amplicon so that you can hit any part.

> [@KMaki](#):
>
> Should be not using the trun-len at all for the extract reads command ?

Correct

> [@KMaki](#):
>
> –p-trunc-len 250 \ #Remove this?

Yes, remove

> [@KMaki](#):
>
> –p-min-length 100 \ #Keep this?  
> –p-max-length 400 \ #Also keep this?

keep both, but adjust to expected ranges (this could also cause unassignments if the ranges are not being set correctly). Check the lit for what the expected amplicon ranges are — setting broad limits probably does not hurt, these are really just used as safeguards, since occasionally some primer sets and reference database combinations can yield some spurious hits that cause issues during classification... unusually short or large amplicons are a good indicator of spurious hits.

> [@KMaki](#):
>
> I got pretty good classification percentages in my other region but maybe this was just luck?

What region was good and what region was bad? Sometimes it's not luck, sometimes it does depend on region, primer, reference db, etc... e.g., I've seen issues with V1 primers on some databases before because some of the reference sequences might not have the correct forward primer included in the sequence. The default settings were designed based on benchmarks of different 16S domains as well as ITS... sort of general "catch all" settings... but for unusual amplicons (maybe?) or for other marker genes (not you, since you have 16S but just saying) these settings may need to be tweaked. Having a mock community to re-optimize for novel primer sets is ideal!

---

<div class="post-metadata">

### Author: ![rparadiso](https://forum.qiime2.org/letter_avatar_proxy/v4/letter/r/4af34b/32.png) [@rparadiso](https://forum.qiime2.org/u/rparadiso)
#### Post date: [April 16, 2020, 10:50am UTC](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476/43 "2020-04-16T10:50:38Z")

</div>

Hello to all,  
I tried your pipeline on my data and it works ..  
first of all thanks to this initiative several times over the years I have asked for it to be created without success so it really seems to me a great thing!  
I have two questions for you:

1. Why do you use sepp for the phylogenetic tree? can't use mafft?
2. There is a way to solve the problem in the alpha diversity? (Faith’s PD is not always enough)

Thank you so much

Rubina

[Previous page](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476.md?page=1)

[Next page](https://forum.qiime2.org/t/possible-analysis-pipeline-for-ion-torrent-16s-metagenomics-kit-data-in-qiime2/13476.md?page=3)
