Strange kmer patterns in FastQC results

[wonaya]

Hi,
I need help in interpreting the fastQC results I have on my sample from paired-end ChIP-seq (151bp long from miseq)

After removing adapter sequences using trim-galore, I am still seeing strange kmer patterns at the 3' end of reverse reads. Does anyone know where these might have originated from, or is it possibly some parameters I've not used in trim-galore?

trim_galore --fastqc -a *adapter_sequence* --paired read_1.fastq read_2.fastq

Thanks.

[Wallysb01]

Does it actually warn you that those abundancies are something to worry about? The plot is just just show the relative frequency to the most abundant kmer, so if that most abundant kmer is very low, it shouldn’t be an issue.

Anyway, for chip-seq, I wouldn’t worry about this anyway, so long as your mappable fraction of the reads is within norms.

[wonaya]

Thanks,

Actually, it did warn me of Obs/Exp Max being 58 for some. I was thinking of trimming the ends, perhaps at 121bp, but the results for forward strands seems fine. I may just go ahead with the alignment and see the mapping.

[Jon_Keats]

Are you sure you are not just reading into the adaptor on the other end of the fragment?

[relipmoc]

It seems that the adapter sequences had not been trimmed for some paired-end reads.

Possible causes:
1. Adapter sequences (one for read1 and the other for read2) were not specified properly;
2. The sequencing error rate is significantly higher than expected (e=0.1 by default), especially in the 3' end regions of the reads.

Suggestions:
1. Double check whether the adapter sequences were specified correctly;
2. Use a higher expected error rate (e.g. -e 0.25).

BTW: I also suggest you try skewer for this task since it's dedicated to trimming adapters in paired-end reads.

Hi,
I need help in interpreting the fastQC results I have on my sample from paired-end ChIP-seq (151bp long from miseq)

After removing adapter sequences using trim-galore, I am still seeing strange kmer patterns at the 3' end of reverse reads. Does anyone know where these might have originated from, or is it possibly some parameters I've not used in trim-galore?

trim_galore --fastqc -a *adapter_sequence* --paired read_1.fastq read_2.fastq

Thanks.

[ChrisAU]

Maybe also try running "fastqc -k 10 ..." to increase the kmer-size fastqc is looking for. That way, you get a better picture of what sequence is at the end of your reads. You most probably have to increase the java heap space for fastqc by editing the file fastqc and setting the number after -Xmx to a higher value.

chris