0
$\begingroup$

I'm having some problems with finding the right parameters to trim my small RNA Illumina reads (51 nt long) with Trimmomatic.

Before trimming, one of the samples (21M reads) looks like this:

enter image description here

So for my understanding, it's quite good and the last two issues can be easily solved with adapter trimming.

I then tried to trim it with the command

java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito3.fastq FemaleMito3_trimmed.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:18

but I got the following result:

enter image description here

So now I have a problem with the sequence quality per tile (why?), an overall drop of the quality at the end of the reads and a warning with the sequence length distribution.

Then I tried trimming just the adapters with this command:

java -jar /opt/Trimmomatic-0.38/trimmomatic-0.38.jar SE -threads 24 -phred33 FemaleMito1.fastq FemaleMito1_noadapters.fastq ILLUMINACLIP:adapters.ultimate.fa:2:30:10 AVGQUAL:25

but again I get some new issues:

enter image description here

Again the per tile sequence quality issue, and now a warning about the GC content.

I didn't find anywhere some precise instruction on how to trim a small RNA library with Trimmomatic. How should I properly trim my small RNA library with Trimmomatic?

$\endgroup$
3
$\begingroup$

The command where you trim with adapters and by quality is perfectly fine. That FastQC isn't perfectly happy is expected. It's a tool made for whole genome sequencing QC, you SHOULD see a number of "fail"s with any RNA-seq protocol. Steps that should always fail in RNA-seq:

  • per-base sequence content (there's "random priming" performed that isn't completely random, so the first ~8 bases show a typical bias pattern).
  • per-sequence GC content (particularly in sRNA-seq you're enriching for a subset of genes, they won't have some nice GC distribution and that's perfectly OK).
  • Sequence duplication level (if this doesn't fail then everything is uniformly expressed...which would be quite unlikely)
  • Overrepresented sequences (as above, though this will be worse for sRNA-seq since reads will often cover the entire transcript, so there's even less sequence diversity)
$\endgroup$
  • $\begingroup$ Thank you for your answer. I expected FastQC not being happy with the sequence duplication level and overrepresented sequences, but I couldn't explain the other two. What about the "per tile sequence quality"? Did adapters inflated artificially the quality of those tiles? Should I do something about that (filter those reads out...) or can I leave them as is? $\endgroup$ – LinuxBlanket Jul 16 '19 at 18:47
  • 1
    $\begingroup$ Yes, it appears that the adapters inflated quality a bit. Don't worry about failed clusters, there's no point in trimming that minor an issue off. $\endgroup$ – Devon Ryan Jul 16 '19 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.