# trim.flows removes 50% of the seqs with only length option

**URL:** <https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066>\
**Category:** mothur bugs\
**Created:** [October 1, 2012, 11:49pm UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066 "2012-10-01T23:49:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kendra](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/kendra/32/112_2.png) [@Kendra](https://forum.mothur.org/u/Kendra)\
**Post date:** [October 1, 2012, 11:49pm UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066/1 "2012-10-01T23:49:38Z")

</div>

I’ve run the SOP on several titanium datasets and have gotten substantially reduced #s of reads (i.e. one set starts with 120k reads, results in 28k). So I’ve backed up through the SOP to determine where I’m loosing the reads. Searching the uncorrected fasta, I find 106k exact matches to the primer and a sum of 103k exact matches to the barcodes. Increasing my pdiffs allowed didn’t change the resulting #s of sequences much. Finally, I tried running trim.flows without the oligos file-using only optional arguments minflows=450(360) and maxflows=450(720). Even that very minor quality trimming, resulted in dramatic reduction of #s 45k for 450flows and 53k for the Quince parameters. This seems really high to me. Is it? or is this the cost of high throughput sequencing-half fails the most basic quality control?

eta:I just check with a combination of gawk and grep 111k sequences in that flow file are greater than 450 flows, so why did they get thrown out by trim.flows??

---

<div class="post-metadata">

**Author:** ![pschloss](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/pschloss/32/4_2.png) [@pschloss](https://forum.mothur.org/u/pschloss)\
**Post date:** [October 2, 2012, 11:33am UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066/2 "2012-10-02T11:33:06Z")

</div>

Well, 454 is notorious for selling crappy reagents that result in bad sequence reads. I’d go back to your sequence provider.

---

<div class="post-metadata">

**Author:** ![Kendra](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/kendra/32/112_2.png) [@Kendra](https://forum.mothur.org/u/Kendra)\
**Post date:** [October 2, 2012, 4:59pm UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066/3 "2012-10-02T16:59:51Z")

</div>

well damn. These are legacy sequences from a former postdoc so probably won’t be doing any more sequencing.

---

<div class="post-metadata">

**Author:** ![Kendra](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/kendra/32/112_2.png) [@Kendra](https://forum.mothur.org/u/Kendra)\
**Post date:** [October 3, 2012, 6:29pm UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066/4 "2012-10-03T18:29:58Z")

</div>

Some of the sequences may just be bad, but I also realized that by amplifying V1-3 (27f/519r) my minimum flows needs to be lower.

---

<div class="post-metadata">

**Author:** ![umjdf](https://avatars.discourse-cdn.com/v4/letter/u/3ab097/32.png) [@umjdf](https://forum.mothur.org/u/umjdf)\
**Post date:** [January 24, 2013, 3:47pm UTC](https://forum.mothur.org/t/trim-flows-removes-50-of-the-seqs-with-only-length-option/1066/5 "2013-01-24T15:47:20Z")

</div>

Hi there,

I’m having a similar problem with a large number of sequences getting thrown out using the trim.flows command (largely due to read length). I find the more I lower the minflows parameter, less reads are scrapped… Is there a minflows value that would be considered just far too low to function as quality control?

Thanks,  
Jessica