# 2021-11-03 trimming/trunc question

**URL:** https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244
**Category:** User Support
**Created:** [November 3, 2021, 9:49am UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244 "2021-11-03T09:49:27Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![marcelpolling](https://forum.qiime2.org/user_avatar/forum.qiime2.org/marcelpolling/32/12180_2.png) [@marcelpolling](https://forum.qiime2.org/u/marcelpolling)
#### Post date: [November 3, 2021, 9:49am UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/1 "2021-11-03T09:49:27Z")

</div>

Hi all,

Thanks for the usefull explanation @lizgehret!

I do, however, still have a question related to this, since I can't seem to get my head around this truncation.

Here's an image of paired-end, 2x250 Miseq reads that were stripped of their FW and RV primers using Cutadapt in both fw and reverse reads. The amplicon size is 158bp for this COI dataset (using specific primers for mites, no variation in amplicon length).

 ![Capture](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/8/8a413315801d1090bb4b9c8fb44a3fd4e7ede3c6.png)

Now if I use the trunc-len parameters, I can only specify the minimum length (I could use p-trunc-len 157). But how do I get rid of the longer reads in this case?

edit: Maybe I should add that my problem would probably be solved I could specify a maximum length in cutadapt.. although then I would have to account for the minimum overlap in the next step..

Thanks so much for letting me know,

Best regard

Marcel

---

<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: [November 3, 2021, 2:27pm UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/2 "2021-11-03T14:27:21Z")

</div>

Hi there @marcelpolling!

> [@marcelpolling](#):
>
> Now if I use the trunc-len parameters, I can only specify the minimum length (I could use p-trunc-len 157). But how do I get rid of the longer reads in this case?

Specifying a trunc-len of X will do two things:

1. Remove 3' nts from every read _longer_ than X in order to bring the read's length down to X
2. Drop any read _shorter_ than X - you can't truncate something that is shorter than the target length.

Keep in mind that for PE seqs the trunc-len parameter is separated _by read direction_.

My first suggestion is to run this through DADA2 with whatever trim/trunc params make sense for removing _the noise_ - then check and see what the output read length distribution looks like - perhaps merging will take care of most of the length discrepancies for you. If not, we can apply some additional filtering _after_ DADA2 - let's check in then.

Keep us posted!

:qiime2:

PS - I moved this out into its own topic, that way its more easily searchable for future readers. Thanks!

---

<div class="post-metadata">

### Author: ![marcelpolling](https://forum.qiime2.org/user_avatar/forum.qiime2.org/marcelpolling/32/12180_2.png) [@marcelpolling](https://forum.qiime2.org/u/marcelpolling)
#### Post date: [November 3, 2021, 4:52pm UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/3 "2021-11-03T16:52:21Z")

</div>

Hi @thermokarst and thanks so much for your quick response 🙂

I've first tried to get rid of the noise using the following trunc parameters in DADA2:

--p-trunc-f 157  
--p-trunc-r 157

Not entirely sure if this is what you meant, but it does produce only features of lengths \>156bp, but running up to 299bp (here's a screenshot of a subset of two samples I'm running just to test this):

 ![image](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/3/3abe4208a9401cbf10ff361d3d73a8b031723a45.png)

If I use any longer trunc-lengths, I remove all my features and nothing is left.

I just came across [this thread](https://forum.qiime2.org/t/filtering-out-asvs-from-dada2-based-on-length/9217/3) where you show how to filter out sequences based on length without having to export. I tried this command using '--p-where 'length(sequence) \< 160' on the features, which works fine (now I only have ASV's of 157-159 bp), but it just feels like I'm working around the truncation step somehow..

Please let me know your thoughts, I highly appreciate the feedback.

Best regards,

Marcel

---

<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: [November 3, 2021, 5:00pm UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/4 "2021-11-03T17:00:53Z")

</div>

> [@marcelpolling](#):
>
> Not entirely sure if this is what you meant, but it does produce only features of lengths \>156bp, but running up to 299bp (here's a screenshot of a subset of two samples I'm running just to test this):

No - not quite - I was referring to the trim/trunc params, and what they do to the sequences in DADA2, prior to denoising and joining. Post-joining (which is what you just shared in your screenshot) is a wholly different beast. The read joining _ideally_ joins in a way that produces sequences that are precisely your target region, but sometimes things go haywire (which is why we have trim/trunc params - removing messy/noisy/problematic nts really goes a long way with improving joining).

> [@marcelpolling](#):
>
> I tried this command

Perfect! That's what I was going to suggest next!

> [@marcelpolling](#):
>
> but it just feels like I'm working around the truncation step somehow..

Hopefully what I just shared above clarifies that you're now looking at what is basically _all new data_ - this isn't a workaround at all. Before you get too far out from your denoising though, let's double check the "Seven-Number Summary of Sequence Lengths". Hopefully you don't have too many reads that are longer than your expected sequence length. If you do though that might be an indication that your trim/trunc params need to be tweaked a bit further before proceeding.

This step of an analysis can be a bit cyclical!

:qiime2:

---

<div class="post-metadata">

### Author: ![marcelpolling](https://forum.qiime2.org/user_avatar/forum.qiime2.org/marcelpolling/32/12180_2.png) [@marcelpolling](https://forum.qiime2.org/u/marcelpolling)
#### Post date: [November 3, 2021, 5:32pm UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/5 "2021-11-03T17:32:57Z")

</div>

Ok I think I got it, and indeed the Seven number summary shows that only a small percentage is longer than the expected 158bp:

![image](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/2X/7/7a2a6e1bcbc272e960955978e818c6a0cdd60b6a.png)

So that means the merging/joining is going well, but just some erroneous ASV's that I can either filter out at a later stage, or using the 'p-where' command?

---

<div class="post-metadata">

### Author: ![system](https://forum-qiime2-org.s3.dualstack.us-west-2.amazonaws.com/original/3X/2/1/21af5fe23cb6f4579467c66a9ed94e55274ca7bd.svg) [@system](https://forum.qiime2.org/u/system)
#### Post date: [December 4, 2021, 11:33pm UTC](https://forum.qiime2.org/t/2021-11-03-trimming-trunc-question/21244/6 "2021-12-04T23:33:42Z")

</div>

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
