Cutadapt only trim primers in some of the samples

Hi, I just find that only part of the samples (both forward and reverse reads) in the product of the cutadapt plugin are without primers. Cutadpat works fine in my other samples before.
Here is my command

qiime cutadapt trim-paired --i-demultiplexed-sequences demux.qza --p-front-f CAGCAGCCGCGGTAATTCC --p-front-r CCCGTGTTGAGTCAAATTAAGC --p-error-rate 0 --o-trimmed-sequences trimmed-seqs.qza --verbose
The log showed that there is minimum or no trimming happened.
Trimming 2 adapters with at most 0.0% errors in paired-end mode ...
Finished in 0.15 s (84 us/read; 0.71 M reads/minute).

=== Summary ===

Total read pairs processed: 1,772
Read 1 with adapter: 4 (0.2%)
Read 2 with adapter: 0 (0.0%)
Pairs written (passing filters): 1,772 (100.0%)

Total basepairs processed: 886,000 bp
Read 1: 443,000 bp
Read 2: 443,000 bp
Total written (filtered): 885,988 bp (100.0%)
Read 1: 442,988 bp
Read 2: 443,000 bp

=== First read: Adapter 1 ===

Sequence: CAGCAGCCGCGGTAATTCC; Type: regular 5'; Length: 19; Trimmed: 4 times.

No. of allowed errors:
0-19 bp: 0

Overview of removed sequences
length count expect max.err error counts
3 4 27.7 0 4

=== Second read: Adapter 2 ===

Sequence: CCCGTGTTGAGTCAAATTAAGC; Type: regular 5'; Length: 22; Trimmed: 0 times.
When I use

qimme tools export trimmed-seqs.qza

to check the exported fastq files, the primer sequences were still there. I just wonder what happened? Thanks a lot.

Hi @chuang - can you provide an example FASTQ record that still has the primer sequence present? If possible, maybe copy-and-paste ~5 of them?

According to the log, your second adapter was trimmed 0 times. It has a length of 22 nts, 3 more than your first adapter - is that correct?

Thanks! :t_rex:

Hi @thermokast, thanks for the reply. Here is an example fastq file still have the primers. This happen to my other data too.

@M00626:396:000000000-BGLYR:1:2106:14857:1563 1:N:0:1
GTGTCAGCAGCCGCGGTAATACGTAGGGTCCAAGCGTTAATCGGAATTACTGGGCGTAAAGCGTGCGCAGGCGGTTGTGCAAGACCGATGTGAAATCCCCGAGCTTAACTTGGGAATTGCATTGGCGACTGCACGGCTAGAGTGTGTCAGAGGGGGGGAGAATTACAAGTGTAGCAGTGAAATGCGTAGAGATGTGGAGGAATACCGATGGCGAAGGCAGCCCCCTGGGATAACACTGAAGCTCATGCAC
+
ABBAAFFFDBCAEC2CAEGGGGHBGFFGGHHFFFGGEGEG5FFEEEFHHGFHHHEE0EDFHHEFE1EEGGCFGG/E//E34F3?22<//?0DDFDFD2FFG/@//<1F1?F1FGCCFGHGHH1FHHG--AGHHEF--..:CCB0;;:[email protected]/B/9B/9///9BBFFFFFBF///A.9=9BB/:BBFBE?.9/FFF?.@FD9B-;99.A?AFD?>FEE./.B/BB/;////9/9/9B/:
@M00626:396:000000000-BGLYR:1:2106:16730:1575 1:N:0:1
GTGTCAGCCGCCGCGGTAATACGTAGGGTCCAAGCGTTAATCGGAATTACTGGGCGTAAAGCGTGCGCAGGCGGTTATGCAAGACCGATGTGAAATCCCCGAGCTTAACTTGGGAATTGCATTGGTGACCGCACGGCTAGAGTGTGTCAGAGGGGGGTAGAATTCCACGTGTAGCAGTGAAATGCGTAGAGATGTGGAGGAATACCGATGGCGAAGGCAGCCCCCTGGGATAACACTGACGCTCATGCAC
+
AABABFFFFDBBGGGGGGGGGGHFGFGGFHHGHGGGGGGGHHGGGFGHGHHHHGHGGFGFHHGFGEFCGGGGGGGFEFHBFGDG2F//<DGDGHHBGGHFGAC/<GFHB1FHEA.FBGDFDBDDFDEBC0<@DDCF?CDHGH00;C;BFFFBADCGF-;AFF/B/BFF.A.BBFBFBFFFBF9BBD.ABE/9:BBFFEFF.FBB/FD?DAD.--99AAFFFFFFFFFFF.BFFFFBFFF9DFBDFBFFFB
@M00626:396:000000000-BGLYR:1:2106:15325:1578 1:N:0:1
GTGCCAGCCGCCGCGGTAATACGTAGGGTCCAAGCGTTAATCGGAATTACTGGGCGTAAAGCGTGCGCAGGCGGTTGTGCAAGGCCGATGTGAAATCCCCGAGCTTAACTTGGGAATTGCATTGGTGACTGCACGGCTAGAGTGTGTCAGAGGGGGGTAGAATTCCACGTGTAGCAGTGAAATGCGTAGAGATGTGGAGGAATACCGATGGCGAAGGCAGCCCCCTGGGATAACACTGACGCTCATGCAC
+
BBBBBFFBBBBBGGGGEGGGGGFFFCEAAFGHHHGGGGDGHFGEGFGHGFHHEEEGGGGHGGG?AFGEGGGFGGEFFEEBGHGAGF?</BFHBHFDFHHGF?///G1<1FGGCGEF0GHB1>FFH0.0C00<GC.--::CCG;0:;G:CGBCE.?DF-.A/B9F;BFFB.ABF///B:FBFEB/B?;.=A///;;BBFFFFF//BF..9.A.@-;@FF??..AAD-A?EFFFF9B9BFFBF?;DDF/F//
@M00626:396:000000000-BGLYR:1:2106:13207:1639 1:N:0:1
GTGCCAGCCGCCGCGGTAATACGTAGGGTCCAAGCGTTAATCGGAATTACTGGGCGTAAAGCGTGCGCAGGCGGTTGTGCAAGACCGATGTGAAATCCCCGAGCTTAACTTGGGAATTGCATTGGTGACTGCACGGCTAGAGTGTGTCAGAGGGGGGTAGAATTCCACGTGTAGCAGTGAAATGCGTAGAGATGTGGAGGAATACCGATGGCGAAGGCAGCCCCCTGGGATAACACTGACGCTCATGCAC
+
BBBBBFFBBBBBGGGGGGGGGGHHHHGGHHHHHHGGGGGGHHGGGGGHHHHHHHHGGGGHHHGGGGGGGGGGGGEGEGFGHHFHEGCFGGHHHHHHHHGGC@DCGHFFFHHHHHEHHHHFFHHHHGGGEHGHHHGGGGGHHHFHGHFGHHFFGGGGFFFFFFFFFFFFFFEFBFFFFFFFFFFFFFDFF.B/BF/BF/EFFFBFFFDDDAFFFFFFFFFFFFFFFFEFF?FFFFFFFFFFFFBDFFFFBF
@M00626:396:000000000-BGLYR:1:2106:17876:1671 1:N:0:1
GTGCCAGCAGCCGCGGTAATACGTAGGGTCCAAGCGTTAATCGGAATTACTGGGCGTAAAGCGTGCGCAGGCGGTTGTGCAAGACCGATGTGAAATCCCCGAGCTTAACTTGGGAATTGCATTGGTGACTGCACGGCTAGAGTGTGTCAGAGGGGGGTAGAATTCCACGTGTAGCAGTGAAATGCGTAGAGATGTGGAGGAATACCGATGGCGAAGGCAGCCCCCTGGGATAACACTGACGCTCATGCAC
+
BBBBBFFBFFFBGGGFGGGGGGHHHHGGHHHHHHGGGGGGHHGGGGGHHHHHHHHEGGGHHHGGGGGGGGCEGGGGFE?GFF3GGF/BCDGFEHHHHHHGCBDGGHFHGGHDFHGHHHDF1FG1<GFGFFEGHHCFCDDHHHFFCGCGFGFGGGGGF-;?FFFFFFFFD.EFFFFEFFFFFFFBFFFDBFFFFFF9//EFDFFFFFFDF.AFCDF-AEFFBFFFFF?EFFFB/BBFFFFFDFBDDFFFFF

The primer can be found at the beginning of the reads:

GTGYCAGCMGCCGCGGTAA

According to the log, your second adapter was trimmed 0 times. It has a length of 22 nts, 3 more than your first adapter - is that correct?

Yes, it is correct.

Can you provide the command that you ran for trimming this primer? I noticed that your original command above is trimming different primers.

I played with the example data you provided in your follow-up post, and was able to trim this primer using the plugin (I won't give the example here, because you only provided one direction in that example), so I suspect there is just a mismatch or a typo somewhere.

Thanks! :t_rex:

Hi @thermokarst , thanks for the update. Here is the command I used:

qiime cutadapt trim-paired --i-demultiplexed-sequences demux.qza --p-front-f GTGYCAGCMGCCGCGGTAA --p-front-r CCGTCAATTCMTTTRAGT --p-error-rate 0 --o-trimmed-sequences trimmed-seqs.qza --verbose

Here is the reverse reads:

@M00626:396:000000000-BGLYR:1:2106:14857:1563 2:N:0:1
CCGTCAATTCATTTGAGTTTTAATCTTGCGACCGTACTCCCCAGGCGGTCAACTTCACGCGTTAGCTACATTACTAAGGAAATGAATCCCCAACAACTAGTTGACATCGTTTAGGGCGTGGACTACCAGGGTATCTAATCCTGTTTGCTCCCCACGCTTTCGTGCATGAGCGTCAGTGTTATCCCAGGGGGCTGCCTTCGCCATCGGTATTCCTCCACATCTCTACGCATTTCACTGCTACACGTGGAAT
+
AAAA?A1BDFBFFGBFGGCG3DG3DGFHHGGGCE0AEEGH/EHEEHGGEGGF1GHFF1EGEGGGFHGHHBHHHHFGFCHHHFHBGBDGH>CFFEGGHEGFEBGHGHH1AFCEFHFF0CCCGGHHEHHHHGC0?GFF1FGHHGFGHGEFGFHGGHGGGFGFHGGECACGHF0ACGFFCGHGHHFFBBBAA-@-ACAAFFFAB?BABBFA--/;BFFFFFFBFBFFB9??BBFFFB//9F/FFFBBFEE-B/
@M00626:396:000000000-BGLYR:1:2106:16730:1575 2:N:0:1
CCGTCAATTCATTTGAGTTTTAATCTTGCGACCGTACTCCCCAGGCGGTCAACTTCACGCGTTAGCTACGTTACTAAGGAAATGAATCCCCAACAACTAGTTGACATCGTTTAGGGCGTGGACTACCAGGGTATCTAATCCTGTTTGCTCCCCACGCTTTCGTGCATGAGCGTCAGTGTTATCCCAGGGGGCTGCCTTCGCCATCGGTATTCCTCCACATCTCTACGCATTTCACTGCTACACGTGGAAT
+
BBABBBAFFFFF6GGGGGGGGFHHHHHHHGEGGCEHGGHHHGHGGGEEFGGHHHHGGGHEEEGGEHHHHGGHHGHHHHHEHHFGHHGHHHGHGGGHHHHHFFHHGHHDDHHCHEFFFCGGFGHHHHHHHGD0FGGHHHHHHHFHGHHHEHHGGHGGGGG.GDGEGGHHHHHGGGGGHHGGFGGGGG0EDA-ABEEFFFFFFFFFFDD9AEFFFFFFEBFFFFFF/BEA?D.;FFFFBFFFFFFFFF.ABB
@M00626:396:000000000-BGLYR:1:2106:15325:1578 2:N:0:1
CCGTCAATTCCTTTGAGTTTTAATCTTGCGACCGTACTCCCCAGGCGGTCGACTTCACGCGTTAGCTACGTTACTAAGGAAATGAATCCCCAACAACTAGTTGACATCGTTTAGGGCGTGGACTACCAGGGTATCTAATCCTGTTTGCTCCCCACGCTTTCGTGCATGAGCGTCAGTGTTATCCCAGGGGGCTGCCTTCGCCATCGGTATTCCTCCACATCTCTACGCATTTCACTGCTACACGTGGAAT
+
BBBBBBBFFFFFGFFGGGGGGGHDGHHHHEFEGEGHGHHHHEFAFFFGFGGGFGGDF3?1EEEEGHBHHGGCFFGG4BGFEFBFGGFHHFGHGGGFE?GGBDGFHEHG/?FCHHGFFF<?DDGHHFFHFGCFCG1FFGHHHFDGHGHHFHHGGFG@GGGEHGCCEG0;C0FDG;AEGF0FBFFFGGB.ABABFDEFFFFFFFFEFFF.9AFFFFFFFFFEFFFBBFEBA.:9BF/B/;;/;BBDFE.D//
@M00626:396:000000000-BGLYR:1:2106:13207:1639 2:N:0:1
CCGTCAATTCATTTAAGTTTTAATCTTGCAACCGTACTCCCCAGGCGGTCAACTTCACGCGTTAGCTACGTTACTAAGGAAATGAATCCCCAACAACTAGTTGACATCGTTTAGGGCGTGGACTACCAGGGTATCTAATCCTGTTTGCTCCCCACGCTTTCGTGCATGAGCGTCAGTGTTATCCCAGGGGGCTGCCTTCGCCATCGGTATTCCTCCACATCTCTACGCATTTCACTGCTACACGTGGAAT
+
BB?AAA>FFFFFGFFGGGGFGGHHHHHHHGGHHGGGGHGHCEHDEFEEGCEHHHHHHGAGEEEGFHHGHGHHHGHHHGGHHHHHHHHHHHGGGGGHGHHHFHHHHGFHGHHGHHHHHGGGGGHHHHGHHGG0@GDHHHHHGHHHHHHHHHHGGHGGGGGGHGHGGEGHHHB-EDDGHEHHHHHHHGFEE-?B@DFFGGGGGGGFFFFDFFFBFFFFFFFFFFFFFFEBFDFFF//BBBFFBBFDFFE.BB
@M00626:396:000000000-BGLYR:1:2106:17876:1671 2:N:0:1
CCGTCAATTCATTTAAGTTTTAATCTTGCGACCGTACTCCCCAGGCGGTCAACTTCACGCGTTAGCTACGTTACTAAGGAAATGAATCCCCAACAACTAGTTGACATCGTTTAGGGCGTGGACTACCAGGGTATCTAATCCTGTTTGCTCCCCACGCTTTCGTGCATGAGCGTCAGTGTTATCCCAGGGGGCTGCCTTCGCCATCGGTATTCCTCCACATCTCTACGCATTTCACTGCTACACGTGGAAT
+
BB@AAA3DFFDFGGGFGGGGFGFHHHHHHEEGGGGHGHHHHGHGGHEGGGFHHFHHFHGHGGGGAGHHHGHHHGHHHHHHHHHGHHGHGHGHGGGHHHHGHHGHHHHGGHHGHBGEHGGGGGHHHHHHGFGGHGFHGDGHHHFGHHGGHHFGGHG-DAFGHFHGGHGHHFEGGGG.GEHGGGGGGGBE.-ABBFGFGFFFFDAEFFDAEEFFFFFFFFFFFFBB/:ABDDFFFFBB/FFBFEF?FF?DFF

When I rerun with this command, it trimmed about 96% reads in some of the samples but certian files like the example reads provided above does only have 0-0.6% of reads got trimmed.

Hi @chuang - are your adapters on the 5’ end, or the 3’ end? The command you provided about is searching only on the 5’ end.

Hi @thermokarst, my adapters are on the 5’ end on both forward and reverse reads.

Okay! Well, to be honest I am not entirely sure what your problem is (from the bits of data you have shared it isn’t clear that there necessarily is a problem or an error, maybe just a misunderstanding or something is subtly off with the commands being run) - maybe you can send me a link (either here, or in a private message) to your data (the file you listed above called demux.qza). I can rerun the command you provided above and try and reproduce what you are seeing, that way maybe I can wrap my head around what is happening. How does that sound to you? Thanks for being patient! :t_rex:

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