Difference in fastqc output after trimming with fastp vs afterqc

Question

[ymberzal]

Hello, Upon trimming ddrad fastq files with fastp, the per base sequence content is still a 'red cross' but after using afterqc, the same is now yellow with an exclamatory mark, indicating it has improved. But upon using stacks, the RE site is not identified in the trimmed clean fastq file generated through afterqc. But the RAD tags are perfectly identified in the fastp cleaned fastq file. What might be the reason?

[rfran010]

How did you specify trimming with fastp? It seems the trimming may be done differently and afterqc has more default qc settings.

[ymberzal]

Thank you for your reply.

$ fastp -i 1A_R1.fastq' -I 1A_R2.fastq --dont_overwrite -q 30 -u 40 --disable_length_filtering --cut_right -c -g -x -o fastp1A.fq -O fastp1B.fq

After I used STACKS to check for RAD cut sites with afterqc trimmed files, this is what I get: 4301656 total sequences 0 failed Illumina filtered reads (0.0%) 0 barcode not found drops (0.0%) 1518 low quality read drops (0.0%) 3839460 RAD cutsite not found drops (89.3%) 460678 retained reads (10.7%)

But fastp trimmed files pass through STACKS perfectly. I was wondering what might be the reason.

[GenoMax]

If you are following the STACKS pipeline you don't need to do separate trimming of the data. I see the following in manual

If you believe your reads may contain adapter contamination, process_radtags can filter it out.

Simply follow the STACKS pipeline.

[ymberzal]

At it now. Thank you!