This is a test version of Biostars. For the public version, visit https://www.biostars.org.
Ribo-seq Trimming Issue: Massive Read Loss in Paired-end Mode

Hi everyone,

I’m analyzing a Ribo-seq breast tissue dataset (GSE210793) and noticed a major drop in read count when trimming as paired-end compared to single-end.

Here are my results:

for sample SRR24150276

Before trimming (R1 raw):

Total Sequences 52,295,695
Total Bases 7.8 Gbp
Sequence length: 150
%GC 66

After trimming (paired-end mode):

Total Sequences 1,524
Total Bases 40.8 kbp
Sequence length 18–32
%GC 53

After trimming (R1 only, single-end mode):

Total Sequences 50,887,136
Total Bases 1.3 Gbp
Sequence length 18–32
%GC 52

When I trim the data as paired-end, almost all reads are discarded. But if I run trimming on R1 only (single-end) using the same Cutadapt parameters, I retain most reads and the FastQC results look normal.

I’ve read that in Ribo-seq, Read 2 (R2) often doesn’t carry meaningful information since Ribo-seq fragments are short (~30 nt). The following paper also suggests focusing on R1 only: https://pmc.ncbi.nlm.nih.gov/articles/PMC6066590/

Could anyone confirm if it’s okay to proceed with only R1 reads for Ribo-seq downstream analysis (alignment, P-site estimation, etc.)? Or is there a recommended way to handle this kind of paired-end data?

Thanks in advance!

trimming paired-end riboseq
• 1,210 views • link
updated by stuart archer • stuart archer • written by Sammy • Sammy

2 answers

Yes, it's standard and recommended to analyze Ribo-seq data using only R1 reads in single-end mode. The short footprint lengths (~28-30 nt) make R2 redundant or uninformative, as it often overlaps with R1 or captures adapters/low-quality sequence. Your trimming results and FastQC look good—proceed with R1 for alignment, P-site calling, etc. If needed, tools like ribotools or plastid handle this seamlessly.

Kevin

• 0 views • link
written by Kevin Blighe Kevin Blighe

I agree with Kevin that you can run with R1 only. However to get to the bottom of what is causing this, you could run R2 though cutadapt as single-end and see what proportion make it through. If it's truly rubbish then you might request a partial refund from the sequencing facility.

I might be wrong but did you use -G in your cutadapt command? A very common point of confusion with cutadapt is whether to use -G or -A to specify adapter sequences to be trimmed from read 2: unless you have a very unusual library prep method, it is almost always UPPERCASE -A ADAPTER that you need to specify for trimming Read 2. The use of -G (or -g) will often cause the entire read to be discarded because anything LEFT of the adapter will be thrown out in the sequence. e.g if you have SEQUENCEOFINTEREST_ADAPTER_RESTOFADAPTER and you specify -G ADAPTER the sequence you will be left with after trimming will be _RESTOFADAPTER which would a) be useless and b) be too long for your length filters because it encounters the adapter only ~20 nt in, so you still have ~130 nt minus the adapter sequence left after trimming - hence the entire read pair gets discarded.

Shameless plug: I've written a trimming visualisation tool which can help clarify what's going on, you just input pre- and post- trimmed fastq files. It's here: https://github.com/MonashBioinformaticsPlatform/trimviz Good luck with your ribo-seq.

• 0 views • link
written by stuart archer • stuart archer

Log in to answer this question.

More posts like this