Hi all, I'm new to this channel. I am working with @Felix Krueger and @Naiara Garcia Bediaga on the Ribo-seq pipeline. After applying it to a sizable amount of experiments, we have noticed a few issues and short-comings, which we would like to improve. Specifically, we are planning the following enhancements: • As described some while ago, SortMeRNA sometimes fails to effectively remove rRNA. We want to get to the bottom of this and possibly tune the parameters to the Ribo-seq use case. • If that fails (due to inherent inapplicability of SortMeRNA to Ribo-seq data), we thought about substituting it for Ribo-Detector for this purpose as plan B. • We frequently get requests for coverage tracks (bigwig/bedGraph and the like) to visualize the coverage of a sample. Adding such a feature should be pretty straightforward and possibly already be available as a bedtools nf-core module or similar. • In its current shape, the pipeline quantifies Ribo-seq data on the basis of annotated genes (as provided by the GTF file). However, one of the main purposes of Ribo-seq is to detect novel ORFs and being able to quantify them. We would like to enable the pipeline to perform quantification on the bases of ORFs as detected from the processed Ribo-seq data. • To this end, we plan on adding a tool for P-site calling for most accurate quantification. We were thinking of Plastid as possible tool for this purpose, though some benchmarking is still required before we choose a tool. I'm aware that adding Plastid has been discussed and dismissed before due to it being redundant to existing functionality in the pipeline. But the enhanced quantification feature would represent a justified reason to include this tool now. We have a prototype script that can quantify Ribo-seq data using detected ORFs and p-sites as input. • A few bugs have been reported for anota2seq on GitHub by @Felix. I will double-check what has (not) been resolved so far and try to fix what's left. • We are considering adding DeltaTE to the pipeline as another tool for DTE besides anota2seq. But I would start with fixing the anota2seq issues, first. • We've got a DESeq2-based prototype script for differential translation analysis (in distinction to differential translation efficiency, i.e., we look at plain differential translation regardless of changes in the underlying transcription, which can be interesting for some biological questions). We would like to add this as a new feature to the pipeline. • To compute differential translational efficiency, both RNA-seq and Ribo-seq data need to be quantified. However, the two modalities are subject to different biases. Namely, Ribo-seq typically uses single-end reads with lengths <=35nt, whereas RNA-seq typically uses paired-end reads with lengths of 50 to 150nt. For this reason, the mappability of RNA-seq data is better resulting in systematic underestimation of Ribo-seq quantification. To mitigate this systematic error, we believe it would make sense to artifically apply the same bias to RNA-seq data (for the DTE component of the pipeline), i.e., trim reads to the same length as the Ribo-seq data and use only the first mate. @Felix Krueger, @Naiara Garcia Bediaga: Feel free to comment if you feel that there is a need for more detail with any of the points.

Hi Sebastian! Great points! • regarding removing contaminants: I have an impression that Ira Iosub's pipeline has a good contaminant list which works well in https://github.com/iraiosub/riboseq-flow • If you include coverage tracks maybe it makes sense to also have a track with only P-sites • I am also interested in including more tools for calling ORFs (but I was unable to make plastid work) - right now I am trying to resurrect ORFquant but will be curious what other tools community might suggest!

Thanks for your feedback! I have given Plastid a spin. It was pretty straightforward. However, I noticed that it calls some sites which it probably shouldn't, e.g. those covered only by multi-mapping reads and some poor-quality alignments with lots of mismatches. Discarding multi-mappers and tweaking the alignment parameters could be of help here. I need to run some more tests to get a better grip of how well the tool performs.

Hi! I already raised an issue - see https://github.com/nf-core/riboseq/issues/110 - and I am incorporating ribowaltz into this pipeline (PR in preparation 🙂 ) and already wrote an nf-core module for it. ribowaltz is regularly one of the top performers for P-site identification. re software choice in particular, I believe we prioritised tools that are also available on bioconda and that are regularly maintained. unfortunately, a lot of high quality ribo-seq software doesn't always fulfill this req.

Hi all, It's time for an update. We have been working on two fronts lately: 1. P-site calling using Plastid 2. rRNA removal using SortMeRNA or RiboDetector We have compared the results from Plastid to data that we analyzed before using other methods. There is good agreement and we are confident that the tool would be a useful addition to the pipeline. We need to jump through a couple of hoops to get there: 1. A nf-core module needs to be created. 2. Test data needs to be added to the nf-core/test-datasets repo. 3. The new module needs to be added to the nf-core/riboseq pipeline. I have developed the code for this, but some more testing is required before it can be pushed to the nf-core repositories. I have tried to get to the bottom of why SortMeRNA underestimates the rRNA fraction. I noticed that with larger file sizes, the fraction of reads classified as rRNA shrinks. It looks to me like a bug. I have filed an issue with details here. The tool has some other issues, namely, it is quite slow (compared to RiboDetector) and consumes a ton of memory on some samples, causing the pipeline to get stuck due to repeatedly failing tasks. Given these issues, I evaluated RiboDetector as an alternative. I found this tool to be at least three times faster and the memory consumption to be low and stable. It also detected a much higher fraction of rRNA in our samples (~30%). While we do not have ground truth information, the fraction detected by RiboDetector seems much more reasonable than SortMeRNA, which often detected <10%. I think it would make sense to add RiboDetector to the pipeline. Again, I have developed and tested the code for this already, but getting it into the pipeline is several steps away: 1. rRNA removal is handled by a subworkflow. The addition needs to happen there. The same subworkflow is used by the most popular nf-core pipeline, namely rnaseq. I'm sure a lot of rigorous testing will be required before a change to this pipeline is accepted. 2. Only after the subworkflow has been updated, we can copy it to the riboseq pipeline. 3. There is a catch: In it's current version, RiboDetector is non-deterministic. It does not use a fixed seed. A PR was submitted two weeks ago to fix this. 4. Of course, the RiboDetector nf-core module needs updating, too, when the seed fix has been incorporated into the RiboDetector tool. I estimate that getting all of these changes in the respective repositories will take several weeks at least. The modification of the

fastq_qc_trim_filter_setstrandedness

subworkflow worries me in particular, because of how entangled it is with other nf-core pipelines. Conceptually, this is where RiboDetector belongs, since it performs the same job as SortMeRNA. But getting it there will take a considerable amount of time to ensure we don't break other pipelines or to convince users of the other pipelines that the tool is applicable in all places.

many thanks for the update here Sebastian. Just a quick question: you mentioned “…it also detected a much higher fraction of rRNA in our samples (~30%). While we do not have ground truth information..” Does RiboDetector use its own files or database to determine what makes a read count as rRNA, or did you feed it the same Silva db FastA files that SortMeRNA uses? I recall having used a simple

Bowtie2

command against those files in the past, where the mapping efficiency went up to >60%. Not exactly sure you are using the same file(s), but in my mind this is a very good starting point for the actual rRNA content. The command and efficiencies might have been reported further up in this channel. @Maxime Garcia: What do you think about the concerns with getting the modules integrated into very popular (sub-)workflows?

Thanks for the thorough analysis of both tools - the performance comparisons are really valuable! One thought: while SortMeRNA has the issues you've identified, since it still works for some datasets (including the

full_test

nf-core data for this pipeline, where it detects ~65-75% rRNA), for implementation, I wonder if the nf-core pattern of offering multiple tools might be a good fit here, similar to how trimmer selection works between Trim Galore! and fastp in the rnaseq and riboseq pipelines. Implementation-wise, we could follow the same structure those pipelines use: keep

--remove_ribo_rna

(true/false) and introduce a new

--rrna_removal_method

param (

'sortmerna'

or

'ribodetector'

) and then have the subworkflow call the appropriate tool conditionally. This might help with backwards compatibility and flexibility, requiring a little less coordination across multiple pipelines. Overall, it is a fantastic addition and many will benefit from it! 🙏

Does RiboDetector use its own files or database to determine what makes a read count as rRNA, or did you feed it the same Silva db FastA files that SortMeRNA uses?

It is a neural network. It has the database built into it's network as far as I understand. No need to feed a FastA reference.

I recall having used a simple

Bowtie2

command against those files in the past, where the mapping efficiency went up to >60%.

Thanks for reminding me about this. I should add this to my comparison. Even the 30% detected by RiboDetector seems quite low. If in the end, bowtie2 is most effective at calling rRNA, I wouldn't even mind using this tool. Heck, it should actually be a pretty easy task to call rRNA, shouldn't it? I'm not an expert in this field, but intuitively I would have thought that a simple alignment should do the trick. Thanks for the implementation ideas, @Ira Iosub. I have implemented it similarly to what you suggest, i.e. give the users a choice as to what tool to use be means of a new parameter. I have removed the (what I thought to be a redundant) parameter

--remove-ribo_rna

, but you're making a good point about backwards compatibility. I should better add this back in.

Indeed, nf-core/clipseq is already using

bowtie

for pre-mapping to rRNA(+tRNA etc), which also gives the flexibility of providing your own contaminants fasta, which can also contain other common contaminants apart from rRNA. Also my pipeline riboseq-flow is using bowtie2 to premap and it works well (it's used in many riboseq papers also). so bowtie2 could be a nice option option for

--rrna_removal_method

. Yep, re

--remove_ribo_rna

, also having the option to not remove rRNA might be the desired option for some users/pipelines

I’ve always been a bowtie user for pre-mapping and never had complaints. It’ll be interesting to see how they all compare. And I agree. Not throwing away the rRNA reads has become much more popular recently

Adding bowtie(2) as a third option should be simple.

Hi all, just catching up. As the author of fastq_qc_trim_filter_setstrandedness and the maintainer of #CE8SSJV3N, I'm confident I can help get that module added there. The best thing to do IMO is add it as an optional alternative to sortmerna with a param to control. I'm confident I could do that quickly

That sounds excellent, Jon!

Tada! https://github.com/nf-core/modules/pull/9462 - also updated tests to actually make sure rRNA removal is happening. Do you have time to review @Sebastian Uhrig?

Thanks a lot, @Jonathan Manning! I will take a look.

Just tidying up after some review, so might change a little in the next wee while, but you'll see what's going on

Do we still plan to add bowtie premapping?

> Do we still plan to add bowtie premapping? Let me run a benchmark to see if it's worth it.

We can certainly add that as an option (though maybe in a separate PR). I've added the auto length inference for Ribodetector to the PR @Sebastian Uhrig , think it should work well.

Gah, I left a comment a few hours ago, but must have forgotten to submit it somehow. I posted it again now.

I can quickly add bowtie as an option to the subworkflow before I install it to the workflow?

thanks for that comparison, that is reassuring! I really wonder what is so different to our internal Ribo-seq data that caused this?

I'm almost done (this AI tooling is embarrassingly useful)! The only cost really is complexity of code.

Ok, then we have a time estimate, too. 13 minutes 😛

Just finalising the tests https://github.com/nf-core/modules/pull/9474 (and may need some refinement) We don't have to keep it if we don't like it

@Jonathan Manning what tools do you use for this kind of development. Claude Code + Seqera MCP or something?

No MCP magic right now, just claude code with thinking

Now I have less of an excuse to get RiboCode in..

Good point @Jack Tierney, I was just about to mention this 😛 I will meet with Jon later today regarding priorities, and RiboCode would be next on the list….

I'll prioritise it. We have found a way to fit it into my work load anyway plus other callers so we can have multiple options there too

That’s awesome!

spotted some issues with the bbsplit PR so it'll be slightly more than the 13 mins 😉 . Will flag for review when it's done and we can make a call

I started working on this adding ribodetector to the nf-core subworkflow a few weeks ago, but you and Claude beat me to it @Jonathan Manning. I unassigned myself from the nf-core/riboseq issue 😉

Oops, sorry about that @Maxime Borry, I should have checked

from a modularity point of view, this seems to make good sense

Code is refactored and ready to go, but we've hit that pesky repro issue with ribodetector (edit), and the way they put the release out doesn't seem to have led to an update to the pypi packages, which is what's needed for Conda availability

RiboCode or RiboDetector?

sorry, yes, the latter

Far too many! >60 according to this out of date list https://github.com/Jackcurragh/awesome-riboseq

Could someone with approval rights approve https://github.com/nf-core/modules/pull/9474 for the bbplit addition/ factoring out? Sebastian approved but isn't in the org (I think)

I have submitted a PR for the addition of a plastid module: https://github.com/nf-core/modules/pull/9482 I also have the code to incorporate the module into the riboseq pipeline, but won't push before the modules have been approved, since there may be change requests which need the pipeline to be changed, too.

Morning all! I've been experiencing a lot of issues getting Ribodetector to run with the pipeline test data, I'm not very convinced it's 'production quality' software tbh. I've made a PR to RiboDetector (with Claude's help) with a fix I've confirmed locally, but for the moment I'm going to disable the pipeline-level tests that use Ribodetector in my pipeline PR. I actually think good ol' Bowtie2 might be the most viable tool we have right now.

Yup, looks like tried and true bowtie2 is the best option.