Earlier today, I ran TrimGalore/FastQC/MultiQC on the Crassostrea virginica MBD BS-seq data from ZymoResearch and hard trimmed the first 14bp from each read. Things looked better at the 5’ end, but the 3’ end of each of the READ1 seqs showed a wonky 2bp blip, so decided to trim that off.
I ran TrimGalore (using the built-in FastQC option), with a hard trim of the last 2bp of each first read set that had previously had the 14bp hard trim and followed up with MultiQC for a summary of the FastQC reports.
TrimGalore job script:
Standard error was redirected on the command line to this file:
MD5 checksums were generated on the resulting trimmed FASTQ files:
All data was copied to my folder on Owl.
Checksums for FASTQ files were verified post-data transfer (data not shown).
Results:
Output folder:
FastQC output folder:
MultiQC output folder:
MultiQC HTML report:
Well, this is a bit strange, but the 2bp trimming on the read 1s looks fine, but now the read 2s are weird in the same region!
Regardless, while this was running, Steven found out that the Bismarck documentation (Bismarck is the bisulfite aligner we use in our BS-seq pipeline) suggests trimming 10bp from both the 5’ and 3’ ends. So, maybe this was all moot. I’ll go ahead and re-run this following the Bismark recommendations.