I'm using Cutadapt in my paired-end FASTQ files for removing primers (forward primer and rev. com. of the reverse primer in forward reads, and reverse primer and rev. com. of the forward primer in the reverse reads). This is my command (wildcards {} are due to Snakemake being my workflow management system):
```bash
cutadapt \
{input.fq_f} \
{input.fq_r} \
--front Primer_F=^{params.primer_f} \
-G Primer_R=^{params.primer_r} \
--adapter Rev_com_primer_R={params.revcom_r} \
-A Rev_com_primer_F={params.revcom_f} \
--discard-untrimmed \
--cores {params.nthreads} \
--output {output.fq_trim_f} \
--paired-output {output.fq_trim_r}
```
I run FastQC on the raw FASTQ as well as on the trimmed FASTQ files, then I MultiQC results. What I found is that The quality per tile section goes from green to red when I trim in all my FASTQ files.
Taking one sample as an example (all samples have the same problem), you can see here the FastQC per tile quality of the raw reads:
![Per tile raw][1]
And then the red in the same FASTQ after trimming primers:
![Per tile trimmed][2]
Trying to find an explanation, I looked into the Per base quality plots. Here you can see the one of the raw reads:
![Per base raw][3]
And for trimmed reads:
![Per base trimmed][4]
(I know the quality at 3' sucks, I plan to use Sickle as my next step but before I need to understand why is this happening)
What I saw is that Cutadapt is in fact removing primers at 5' end (since this data comes fro ...
↧
