[liguanghao]

I use TrimGalore to trim adapter and the fastqc result also show that there are biases in 5' end, several kmers occurring.

[arkanion]

Use Trimmomatic

[Brian Bushnell]

The fragmentation sites may be biased, depending on how fragmentation was done. Try mapping with BBMap and using the 'mhist' output, which shows the error rate by read position. If the error rate on the 5' end is not much higher than anywhere else, there's no need to trim it.

[Brian Bushnell]

BBDuk can trim a set number of bases on the left or right side of a read. However, there are some library-prep protocols that are biased, especially near the read start, and thus have suspicious base-frequency histograms, even though they are correct. So, before you trim, I suggest you map the reads to a reference (even the lowest-quality assembly is OK) to determine whether there is actually a higher error rate in the first X bases of the read. If not, then you should not trim them.

With an assembly, you can determine it like this:

bbmap.sh in=reads.fq mhist=mhist.txt qhist=qhist.txt

This will give you histograms of the average qualities by read position, and match/substitution/insertion/deletion/N rates by read position. That will allow you to determine whether the stated read quality is accurate, and thus whether you need to trim the ends of reads.

If you want to trim a set number of bases on each side, you can use BBDuk's "ftl" (force-trim left) and "ftr" (force-trim right) flags to set the limits of where to trim.

[Oyster_lab]

Thanks for your reply, Brian.
I have mRNA Illumina 100bp paired end reads. I have already removed the adapters, but still have that same the high variation on GC% at the 5' end. For the library prep, TruSeq mRNA prep was used, that's why I am guessing I have the same 5' end bias described before on my dataset. Any thoughts?

[Brian Bushnell]

It depends on the library prep. Illumina fragment libraries typically have adapters on the right (3') end, so if you trimmed to the left from the adapter you'd lose all of your genomic sequence. For long mate pair libraries, the answer depends on the protocol.

[Oyster_lab]

So, just following up on this topic. It has been incredibly helpful. We shouldn't trim the first bases at the 5' end and try to perform the de novo assembly that way correct?

Thanks!

[nareshvasani]

I did the same way.

Thanks for feedback.

I always use the fastx_trimmer; you can use the -f and -l options to set the first and the last base to be kept.

[nareshvasani]

Thanka a bunch.

You can use cutadapt to trim both 5' and 3' bps. The fastx_clipper can only trim 3' end. When you use cutadapt, you must use cutadapt -g firstly, and use the processed sequence to do cutadapt -a. If you use -g and -a at the same time, it will only cut one end.

[Michael.Ante]

I need help. Can you please help me to trim both ends 5' and 3'?

Thanks in advance.

I always use the fastx_trimmer; you can use the -f and -l options to set the first and the last base to be kept.

[Tengfei Liu]

I need help. Can you please help me to trim both ends 5' and 3'?

Thanks in advance.

You can use cutadapt to trim both 5' and 3' bps. The fastx_clipper can only trim 3' end. When you use cutadapt, you must use cutadapt -g firstly, and use the processed sequence to do cutadapt -a. If you use -g and -a at the same time, it will only cut one end.

[nareshvasani]

Hi IBseq

I sorted that out...if anyone needs info glad to help

I need help. Can you please help me to trim both ends 5' and 3'?

Thanks in advance.

[isett]

What if it's WGS and not RNA-Seq. I see the same thing with the NexteraXT kit on the MiSeq. Is it a non-random recognition site for the Tagmentation enzyme?

[rmred]

I got the same problem to and produce exactly the same ACGT bias for the first 15bp/cycle. And I've asked the representative for Illumina and they mentioned that this is due to the hexamer random priming as mentioned above.

[TonyBrooks]

Hi folks - hope some of you can help me clarify something about adapter contamination and adapter trimming.

I made TruSeq Illumina libraries and sequenced them for 100bp paired end reads.

When I view the 'per base sequence content' with fastQC I get something that looks like adapter contamination. I then used cutadapt to remove the adapter sequence. The 'per base sequence content' before and after cutadapt is shown in the attached pdf.

Now this is all fine and dandy but what I find a bit confusing is why the adapter sequence is at the beginning of the read. My understanding was that adapter contamination mainly arises when the read is too short so at the end of the read the sequencer starts to sequence the adapter.

So why does the adapter appear at the beginning of the read and not at the end?


Am I misunderstanding something? I would love to have a clarification of this.

Thanks,
blanco

You can get adapter-dimer (where the DNA insert size is effectively 0) meaning that you only sequence adapter (hence it appears at the 5' end). If this is the case, I believe using cutadapt willl just remove those reads from your fastq file (maybe someone can confirm).
Those peaks don't look like dimer to me, more the random priming issue. When you get bad adapter, you can actually read the adapter sequence in your %base graph (see attached plot of a run that had 10% adapter dimer).