I encountered an issue with the bowtie rrna removal due to duplicate sequence naming (or at least what some tools interpreted as such). Anyone here care to review the fix? https://github.com/nf-core/modules/pull/9522

@Sebastian Uhrig could you head on over to #CEB982K2T and get yourself added to the nf-core org? I noticed your tests weren't running, your reviews aren't valid etc, that will be fixed when you're a member

I'm just sorting out some snapshot mismatches, but could some review on the rrna removal method integration in the workflow? https://github.com/nf-core/riboseq/pull/125? It's got a scary number of file changes, but it's mostly stuff reviewed upstream in nf-core/modules, just focus on the changes to the pipeline logic and documentation.

@Sebastian Uhrig @Jack Tierney @Naiara I've just about finished with the feature @Felix Krueger asked for around truncating the paired rna-seq reads before alignment/ quantification, I wonder if you might like to review? https://github.com/nf-core/riboseq/pull/135 I must say that the idea seems odd to me, but I'll take the expertise of those more native to this field.

I have added the new plastid module to the riboseq pipeline, in case anyone has time to review: https://github.com/nf-core/riboseq/pull/134

Hi all! I'm on xmas holiday as of right now, but I've got something done to discuss / merge in the new year: • Optional alignment-free path for translational efficiency as a potential alternative to the hard trimming stuff (not sure how folks feel about this, but it's there for illustration if nothing else): https://github.com/nf-core/riboseq/pull/137 • Minor MultiQC config fixes: https://github.com/nf-core/riboseq/pull/138 (if someone could approve that I've left it on auto-merge) • Added some ribowaltz qc plots to the MultiQC report: https://github.com/nf-core/riboseq/pull/139 @Ira Iosub I know you added that stuff, so may have thoughts- there is an example report attached to the PR. I picked the easiest/ most useful-looking things, but we can do others. See you all on the other side!

Hey @Jack Tierney, I did a bit of fixing up in https://github.com/nf-core/riboseq/pull/136, but think it's good to merge now, when you're ready (and the tests pass)

I just thought I would quickly post here some frustration my experiences with

ribodetector

over the last 4 days. In the first instance, this process uses 36 GB of RAM. It continued to fail after raising it 188 GB, and also 388 GB. After allowing it to use 688 GB of RAM it then timed out after 8h, 16h, and 24h. (Note: this is a run with 3 samples). Switching over to rRNA removal using Bowtie 2, all removal processes finished within 40 mins without any issues.

Here is a PR which implements coverage tracks, for review: https://github.com/nf-core/riboseq/pull/144/

I PR'd a fix for our Ribodetector issues before xmas, looks like it's in a release now: https://github.com/hzi-bifo/RiboDetector/pull/61#issuecomment-3861504296

Quantifying novel ORFs I would like to start a discussion about another potential feature for the pipeline. I have started working on this, but figured it probably makes sense to get feedback from the community/main developers of the pipeline, before storming off into the wrong direction. Currently, the pipeline only quantifies ORFs annotated in the GTF file. At the same time, it includes several tools to detect novel ORFs (Ribotish, Ribotricer, RiboCode). Those novel ORFs are not usedin downstream analysis, though (notably, in differential translation and DTE analyses). Is there a particular reason for this other than "we didn't have the capacity to implement this yet"? My current plan is the following: 1. Use consensus ORFs from Ribotish/Ribotricer/RiboCode (ideally user-configurable) 2. Expand the canonical GTF by the novel ORFs 3. Requantify ORF translation from Ribo-seq data using the modified GTF. There are two ways (both of which could be incorporated into the pipeline and offered as a choice to the user): a. Rerun Salmon => complicated, because (1) it will require running the entire quantification workflow - including index generation - nested within the main workflow and (2) Salmon was not really made for the case where there are multiple ORFs for the same transcript. It gives strange results in situations where transcript coordinates are 100% identical: assigning 0 counts to one and the rest of the counts to the other. We would thus need to merge and un-merge transcripts/ORFs before passing them to Salmon and somehow split the counts among the ORFs after unmerging. b. Pass the modified GTF to the in-frame P-site counting => straight forward to implement, but the in-frame P-site counting is under debate 4. Run DTE on the new counts The situation is a bit tricky for ORFs which originate from one and the same transcript. DTE always needs RNA expression for normalization, but you cannot have the same reference transcript for two (or more) ORFs. We would need to synthetically create new transcripts as copies of existing ones and then normalize the novel ORFs to those synthetic transcripts. For example: Let's say a transcript

ENST123

has two ORFs, a canonical one

cORF

, and a non-canonical one

ncORF

. We could use

ENST123

as the matched RNA expression for

cORF

, and a synthetic transcript

ENST123-copy

as a match for

ncORF

. But how to define the counts of the synthetic transcript? Should they be split equally between the

ENST123

and

ENST123-copy

? Or would it be better to duplicate them? In my tests, duplicating the counts seemed better. For example, if

ENST123

had a count of 50, and I made a copy

ENST123-copy

with the same count (50), the DTE results of

cORF

vs.

ENST123

were more stable than when I split the reads among

ENST123

and

ENST123-copy

(25 each). Of course, I did not test this with a single transcript; I ran my tests on 10% of the transcripts.

Hi all, we were just reviewing a recent run of the workflow with Bowtie2-based rRNA removal (which worked well). For a test sample, 46 million sequences survived the adapter/quality filtering and rRNA-filtering, and were fed into STAR. Around 36M sequences aligned either uniquely or multiply. The UMI-deduplication using UMI-tools reports however: 12M alignments left over 82M alignments removed This is obviously a lot more alignments that had been fed in, so I assume it also uses secondary alignments. At least in my mind, these stats are not really what we would like to have reported, as we would like to go from

raw reads

to

trimmed_reads

to

non_rRNA_reads

to

aligned_reads

to

deduplicated_reads

, as a QC metric for the experiment/library/CRO. Could we instruct UMI-tools to only consider primary alignments, or filter to primary alignments before (

samtools view -F 0x900)

? Alternatively, should we limit STAR to output only a single alignment, such as with:

--outFilterMultimapNmax 1

? Any opinions? @Jonathan Manning

I have implemented another alternative quantification method for Ribo-seq reads. Details here in case anyone has capacity to review: https://github.com/nf-core/riboseq/pull/141

Hi there, quick question about Ribocode. In my experience over the past few weeks, Ribocode in the dev version keeps crashing and runs only complete when

--skip_ribocode

is selected. I think I’ll have 2more Ribo-seq runs later today or tomorrow, so I was wondering if this has been looked at/fixed by any chance? Many thanks! @Jonathan Manning @Jack Tierney

Hi all, first of all thanks for the great pipeline you provide here. I have a conceptual question. Just got libraries where the RNASeq part has UMIs embedded in the reads while the RiboSeq part doesn't have UMIs. Is this something the pipeline can deal with or would I have to extract UMIs first, add them to the read name and add a pseudo-UMI to the riboseq names that is just the same for all reads and then run with the

--with_umi --skip_umi_extract --umitools_umi_separator ":"

parameters?

Finally deployed that ribodetector update: https://github.com/nf-core/riboseq/pull/152

I'd like to add cleanup blocks to our tests, to avoid a problem @Sebastian Uhrig encountered. We solved it this way in #CE8SSJV3N: https://github.com/nf-core/riboseq/pull/153. Review appreciated!

If anyone feels like a review, just need to fix linting to unblock other work: https://nfcore.slack.com/archives/CQY2U5QU9/p1777559813900389

Could someone here review this one? It's adding the Ribowaltz functionality from the last MultiQC release, but also mopping up a few MultiQC reporting issues I noticed at the same time: https://github.com/nf-core/riboseq/pull/154 There are before/ after reports on the PR

Dear all, We*** are about to embark on a new round of adding functionality, fixes and improvements for our favourite Ribo-seq workflow - do expect some activity here and/or on Github soon, and please engage as much as possible to get the best possible outcome for everyone (* @Jonathan Manning, @Naiara, @Sebastian Uhrig). In an attempt to enable the use of ORFs for downstream analysis (instead of just canonical genes quantified by Salmon), we set out run a benchmark of 6 different ORF callers, namely

RiboCode, Ribo-TISH, Ribotricer

(already in Ribo-seq), as well as

PRICE

,

Rp-Bp

and

RibORF

(not (yet) in Ribo-seq). The additional tools

RIBOSS

or

Rp3

were excluded from the benchmark as they had additional requirements. Please see the attached benchmark report below, happy to hear your experiences and feedback. As a quick note: the tools for this run were hand-selected by @Naiara and several of them had been tested (manually) on the dataset before (a dataset of good quality with credible biological outcome, 2 groups, 3 technical replicates each). The engineering and orchestration was aided by jean claude code van damme . Here are the main takeways: • Tier-1 cohort (recommended production defaults):

RiboCode

(mean Spearman 0.917, 6-26 min/rep, biology-correct uORF/dORF 1.7-4.0×) and

Rp-Bp

(mean Spearman 0.893, ~20-24 h/rep, biology-correct uORF/dORF 3.4-5.2×). Both tools have non-overlapping personalities:

RiboCode

is a permissive canonical-CDS caller;

Rp-Bp

is Bayesian-strict. • *Tier-2 cohort (opt-in specialists): `Ribo-TISH`*(alternative-start-codon discovery within annotated CDSes; calls ~60% Truncated alt-starts) and

PRICE

(near-cognate start-codon detection; only 29.7% AUG vs 70% non-AUG CUG/GUG/AAG/UUG/AUU/AGG/ACG/AUA — unique non-overlapping niche). • Excluded:

ribotricer

(mean Spearman 0.288 — rank-unstable scoring across replicates makes its score column unusable for production);

RibORF

(is operationally untenable at genome-wide scale — readDist.pl re-parses the SAM file once per read-length class, projected 5-7 days per replicate on this cluster’s hardware);

RIBOSS

(missing RNA-seq dependency);

Rp3

(missing proteomics dependency). PS: Slack appears to block all attachments currently (issue: https://slack-status.com/2026-05/fe557ca05fdb64fa), I’ll retry once this technical issue is fixed.

That all sounds excellent to me. Thank you all for all of your efforts. I'll do my best to chip in where I can

<!channel> - I've created #C0B5DGK8AQG, following the standard pattern, to avoid spamming the whole channel with the upcoming burst of dev discussion. Interested parties please make your way there!

Anyone in? https://nfcore.slack.com/archives/CE6SDBX2A/p1786363627423669

✅ riboseq/test_full completed successfully! 🎉 Run Name compassionate_fermi Duration 2h 51m 23s Status ✅ Success Tasks Completed: 371, Failed: 7 Sep 15, 2026 at 12:55 PM

Release 2.0.0 is out! github.com/nf-core/riboseq/…/2.0.0

Thank you for all of your work @Jonathan Manning!

✅ riboseq/test_full completed successfully! 🎉 Run Name reverent_cray Duration 3h 9m 11s Status ✅ Success Tasks Completed: 371, Failed: 8 Sep 15, 2026 at 7:50 PM

✅ riboseq/test_full completed successfully! 🎉 Run Name adoring_shannon Duration 3h 1m 43s Status ✅ Success Tasks Completed: 371, Failed: 7 Sep 15, 2026 at 8:05 PM

depictio Depictio dashboard for riboseq: your feedback wanted Hi all! 👋 I am building Depictio, an open-source platform from EMBL to explore pipeline results without writing a Shiny or Streamlit app each time. A pipeline gets a dashboard template: a short definition that turns the outputs of any run into an interactive dashboard. I am now sharing it more widely, so I would like the view of riboseq users and developers. ✨ What it does • MultiQC reports (aggregated across runs) next to result tables, images, phylogenetic trees, maps... with linked filters • Reusable: point the template at any new run of the same pipeline and you get the same dashboard • Fully editable: modify any dashboard from the GUI or in YAML, so the template is a starting point, not a constraint • Versioned, with comments and annotations on any component • Runs as a Python package, with Docker Compose or on Kubernetes, and can serve as a companion web app for a publication 🔬 For riboseq: footprint periodicity and reading frame, library separation, translational efficiency and regulation, and ORFs called by Ribo-TISH and RiboCode, next to the MultiQC report. ⚖️ Compared with shinyngs: for the differential expression part, the usual route is nf-core/differentialabundance, which builds an R/Shiny app (shinyngs) from a matrix and a design. Depictio is not tied to R or to one data type: it shows the same kind of results (PCA, volcano, MA, GSEA) next to the MultiQC report and the other outputs of the run, behind one link, with versioning and comments. I see it as complementary: shinyngs is made for exploring expression data, Depictio for sharing the whole run. 👀 What I need: I have built 25 templates and want people who really use these pipelines to review and criticise them. What is useful? What is misleading? 👉 Dashboard: riboseq dashboard (no account needed) 💬 Comment on the dashboard (Google sign-in) or in the GitHub discussion dedicated to riboseq. ⭐ A star on the repo is welcome if you find it useful. Thanks! 🙏 🎤 In you're interested in the project, I was speaking about Depictio at the Nextflow Summit (session page), and the recording will be available in the coming weeks.