# Differences in representative sequences between QIIME1 and QIIME2

**URL:** https://forum.qiime2.org/t/differences-in-representative-sequences-between-qiime1-and-qiime2/6812
**Category:** User Support
**Created:** [November 6, 2018, 12:54pm UTC](https://forum.qiime2.org/t/differences-in-representative-sequences-between-qiime1-and-qiime2/6812 "2018-11-06T12:54:53Z")
**Posts on this page:** 1
**Showing post:** 21

<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: [November 14, 2018, 4:40pm UTC](https://forum.qiime2.org/t/differences-in-representative-sequences-between-qiime1-and-qiime2/6812/21 "2018-11-14T16:40:37Z")

</div>

> [@cdeai](#):
>
> Only 35 🤦‍♂️ sequences left after debluring [deblur-table.qzv](https://forum.qiime2.org/uploads/qiime21/original/2X/2/2404f2be9e021ce022c1cf8cc62692c93e70cb7f.qzv) (315.4 KB)  
> The statistics file [deblur-stats.qzv](https://forum.qiime2.org/uploads/qiime21/original/2X/e/e3854d3b0decdecfac80eefdff12f62af3f5d36e.qzv) (205.6 KB)

The issue with deblur appears to be that many of the sequences are unique and/or do not resemble the reference sequences you input (e.g., are non-fungal). See the `fraction-artifact-with-minsize` column in the stats visualization. You can adjust the `min-size` parameter to correct for this, if unique seqs are to blame (as I suspect) — however the deblur developers have warned against this, e.g., see [here](https://forum.qiime2.org/t/figuring-out-why-sequences-are-lost-in-deblur/6718) (that user has a similar issue with deblur).

> [@cdeai](#):
>
> 1. Result: Better, _but_ still up to two thirds of sequences are removed - in this case in the step between the denoised to non-chimeric data [denoising-stats.qzv](https://forum.qiime2.org/uploads/qiime21/original/2X/2/2e3b31b9fe25c0202741054e2dd94b13aaa41c1f.qzv) (1.2 MB)

Aha, yes that could be the issue — if these sequences are being filtered out as chimera on single-end, they are probably noisy reads that have issues passing filter/merging with the paired-end. QIIME 1 does not use chimera filtering by default so that could explain part of the discrepancy.

Personally, I think I would proceed with the single-end data. It is probably better to have slightly shorter reads rather than proceed with longer joined reads but potentially introduce an amplicon length bias (which is essentially what is occurring, and clearly impacting some samples more than others).

But I recognize that is not satisfying, when QIIME 1 seems to yield better results (the possibility that chimeric seqs are passing through and masquerading as real data may taint that assumption, though, depending on if you used a chimera filter with the qiime1 results). You could also use q2-vsearch to perform OTU clustering and see if that performs better for your data. I linked to the OTU clustering tutorial above. Your workflow would look like this:

1. use q2-quality-filter to trim/filter sequences
2. use `vsearch dereplicate` to dereplicate seqs
3. use q2-vsearch to cluster
4. use q2-vsearch to filter chimera

> [@cdeai](#):
>
> Does this mean there is a deeper problem with the input data I’m somehow missing?

The chimera filter seems to suggest that it is a problem with the data — the sort of problem that can be fixed. Use single-end or try again with q2-vsearch and compare against (chimera-filtered) QIIME 1 results to see how they square up. Let us know what you find!

---

_[View the full topic](https://forum.qiime2.org/t/differences-in-representative-sequences-between-qiime1-and-qiime2/6812)._