@Felix Krueger I looked into deltaTE as you asked, and as far as I can see it's just an R script dumped on a Git repo 4 years ago. So I'm a bit trepidatious about including that here. Because it's not properly packaged or anything we must bake it into the pipeline and pipeline maintainers become solely responsible for the scientific logic. That said, it's based on very basic DESeq2 code so not hard to replicate, and I have worked it up for folks to review fully in the pipeline context: https://github.com/nf-core/riboseq/pull/128 . Right now the module is 'local' rather than in nf-core/modules, we can make a call on that if we confirm we want this. What do you think? (also CC @Jack Tierney @Ira Iosub @Sebastian Uhrig )

Also adding @Naiara here for comment

Ahh yes, thanks!

I can talk with Sonia Chothani and Owen Rackham about them packaging it. Sonia has just started a lab at A*STAR and Owen is back in Southampton

I can also PR a packaging if it would help, I didn't know if anyone even cared about the code since it's not been touched in 4 years

Tbh, I have always used and recommended DESeq2 directly for this type of analysis. It just requires modelling the assay type as well in the design formula

I believe that is all DeltaTE does for you anyway

I think a local DESeq2 module is perfectly fine for this task

Ola Larson (Anota2Seq author) has a great (and old) paper that describes why differential translation analysis is inherently tricky. I would be cautious about presenting the local DESeq2 differential expression analysis from this workflow as robust. https://pmc.ncbi.nlm.nih.gov/articles/PMC30

We could provide it as an option at least with a pointer to those provisos

Yeah its strict but I'd believe the outputs whereas theres always an asterisk next to the less restrictive analyses for me. Part of that comes from being aware of my own ignorance though so basically 'user discretion is advised'

Naiara said she would share her thoughts here tomorrow (currently busy)

@Jonathan Manning I completely agree with the hesitation regarding the original DeltaTE script. It is not a proper package, and we certainly shouldn't just "dump" the script into the pipeline. However, I am advocating for the DeltaTE methodology (specifically the interaction term logic) rather than the script itself. The real value lies in the Ribo:RNAseq interaction term:

~ Condition + AssayType + Condition:AssayType

This framework provides a powerful way to classify genes as buffered, intensified, exclusive, or forwarded, by running three models (RNA, Ribo, and Interaction) and combining the outputs. While the original GitHub script is rigid (limited to two groups, unable to adjust for covariates), a native DESeq2 implementation of this logic can be very flexible. While the concept is simple, setting up this specific interaction model—and coordinating it with the independent RNA and Ribo models—might not be immediately obvious to users who are not seasoned in Translation Efficiency (TE) analysis, and hence I proposed its addition. Regarding anota2seq: It uses a regression-based approach (APV) that handles "spurious anticorrelation" between the RNA:ribo ratio bias very well. This spurious anticorrelation is particularly challenging in lowly expressed genes. The DeltaTE-style framework also addresses the noise in lowly expressed genes via logFC shrinkage (using

lfcShrink()

). By shrinking the fold-changes of lowly expressed genes, DESeq2 essentially prevents those noisy "ratio artifacts" from becoming significant hits. When I compared these two side-by-side a few months ago, I observed that anota2seq was significantly more conservative than the DeltaTE-style framework. In fact,

anota2seq

yielded almost no significant hits in a model where specific changes were biologically expected. My proposal is to keep anota2seq (100%), but to also add the "DeltaTE-style" framework (using standard DESeq2) as a complementary alternative that is less conservative and more flexible for complex experimental designs, yet remains statistically rigorous.

Thanks for that input @Naiara. The PR at the top of this thread duplicates the delataTE script, with more modern R syntax. Is that sufficient, or would you like to make any modification?

I am still supposed to be busy, but I couldn't resist replying. I can send you the script I've been using tomorrow, so we can evaluate it together?

I'm mostly prepared to take your expertise. If you send me your script tomorrow I can have my AI friend synthesise it with what I already have 🙂 . Good night!

Awesome!

OK, it took a little bit of iteration, because I wanted to harmonise language between our 'deltate-a-like' and anota2seq, but it's ready for review at https://github.com/nf-core/riboseq/pull/128. I'd love any of you to give it a try when you have time, but especially maybe @Naiara. Some of the terms will be different to your implementation because we're matching anota2seq, but I didn't want to confuse users for no reason. I've updated the docs to use the results of the

test_full

profile with both methods. I'm still working on snapshots to make the tests pass.

Thanks, Jonathan. I’ll look into it by tomorrow.