Good morning all, Great to see all the movement here, and that riboWaltz PR is now ready to go! As a little update from our side, quite some work has gone into a comparisons between Plastid and ORFquant, I am sure Sebastian can give an update on this soon. @Jonathan Manning is planning to integrate the RibotishQC into MultiQC this week, which should be a great QC feature for Ribo-seq data! As next steps, we would be looking to integrate Ribocode as an optional tool into the Ribo-seq workflow. @Jack Tierney we know that you have already made a start on this some 2 years ago (https://github.com/JackCurragh/custom-nf-core-modules/tree/main/modules/jackcurragh/ribocode), is this something you intend to finish, and/or have time to do? If not, we could ask for assistance for this from Jon? In terms of a new release, as Sebastian outlined earlier we intend to add a few new features and fix some issues over the coming few weeks (hopefully this side of Christmas), but this shouldn’t be a reason to delay a release if you feel that there should be one soon. We could always aim for another release to start the New Year?

Work in progress: https://github.com/MultiQC/MultiQC/pull/3384

Thanks Felix. I think the blocker I hit at the time was the lack of appropriate test data as RiboCode fails when given low periodicity samples. I will have another look at it this week and if I feel its above my capacity I will report back rather than letting it run on any longer un-done

hey @Jack Tierney . for

RIBOCODE_PREPARE

only fasta and gtf needed, so prolly what you have is closer than you think! for the rest (assuming there's no test data already uploaded that satisfies the periodicity requirement, worth checking first) - for anyone going forward with it - in case helpful, I successfully used ribocode with these samples

SRR9693978

and

SRR9693980

(good data in mouse). i guess it's a matter of downloading, sub-sampling the fastqs, running the riboseq pipeline on them (also useful for pipeline testing actually) and uploading the BAMs (the ribocode input) as a PR into https://github.com/nf-core/test-datasets/tree/modules. then we can write the module tests to use this data.

That sounds like a great way forward!

Are the existing alignments not worth a go @Ira Iosub? https://github.com/nf-core/test-datasets/tree/modules/data/genomics/homo_sapiens/riboseq_expression/aligned_reads

Great work on the Ribotish module, @Jonathan Manning! @Jack Tierney, @Ira Iosub: Can you please take a quick look at the very first Example Report https://github.com/user-attachments/files/23460461/ribotish_example_report.html that Jon attached in the PR here (https://github.com/MultiQC/MultiQC/pull/3384). Do you like the terms Frame 0, Frame 1 and Frame 2 (or F0…)? Or is there a better term for that that is preferred in the field?

Frame 0, 1, 2 is what Ingolia used in the initial paper and its quite commonly used but I have seen 1 indexed also. I think its good as is. The one thing I mildly object to is saying >70% periodicity is good quality Ribo-Seq. While good quality Ribo-Seq will often have high periodicity and poor quality often have low, there are so many caveats to it that I'd prefer to be less opinionated in what many non-Ribo-Seq people may see as a reference pipeline. I am not familiar with writing multiqc modules and perhaps these kind of guideline interpretations are recommended but thats my intuition on it anyway

It's definitely a work in progress, I'll take comments from here, but feel free to comment on the PR for posterity too (if you have permissions)

@Jack Tierney precisely, that's what i said, worth checking our existing alignments first! (the dataset addition suggestion is backup) i had forgotten i uploaded both the genomic and transcriptomic BAMs 🙂

The heatmap is based on @Felix Krueger’s prototype code, but we can certainly flip to a line graph view if there's consensus that that would be better

Happy to go with with more conventional or typical representations, could we get a line graph underneath to see the difference? In my experience, line graphs tend to get messy if you plot some 20-60 samples?

I am thinking sth fastqc-esque. And it can get messy, but multiQC allows users to filter on subsets/select samples if one wishes to while viewing. but honestly, I am happy either way

Here's a take on the MultiQC report with both the line plots and the heatmap. To my eye the line plot does a much better job of showing the shift in distribution between samples, so I'm with @Ira Iosub

I agree, keeping both would be great (maybe with a little button switching between the two)? In my example code I used to have line graphs at first, but this became unworkable with dozens of samples, which is when the heatmap came in….

I don't think we can have a switcher with native MultiQC stuff (I tried quickly), but I think it works fine like this

I quite like them (maybe a bit finer and without text) for orientation. What do others think?

Looks nicer in the HTML

We (as in, you) are so getting there! 👏

If you look carefully at the commits you'll see that this has been AI-accelerated 😉. Perfect job for Claudy-C, rapid prototyping until you get what you want.

just looked at the example multiQC report, it looks really good! I also like the switch away from the diverging color scale for the heatmap

Hi folks, looking at this PR now (there's been quite a bit of upstream work to get to this point - the new sample grouping bargraph stuff is now merged)

I don’t want to die for this, but as discussed the line graph becomes rather messy and un-interpretable with many samples (isn’t there test data with ~70 samples?). Would it be a lot of work having a heatmap/line graph button so one can switch back and forth if required? The codebase for it is there, so it seems a little wasteful….

Would it be a lot of work having a heatmap/line graph button so one can switch back and forth if required?

Yes, quite a lot of work

That might be an option. This is an example:

No need, Phil has a strong opinion 😅

I’m sure you’ve got an opinion on a good threshold? 30 maybe? But don’t you want to write a good prompt first to see how hard it would be to have linegraph/heatmap first?

I have Claude going in the background already for the toggle button, I just don't want to delay getting this PR merged any longer.

ah there we go. Just 1 toggle button, how hard can it be?

For quite a simple / short module, this PR has created more core-MultiQC work than any others for quite a while 😅

I think we discussed back at the hackathon in Oct 2024 that this kind of data is a little tricky to get into MultiQC 😛

This is why we can't have nice things claude lurk

Hey, I said it was the first scrappy AI draft!

Wrong thread 😉

(for context for observers, I thought Phil was referring to my latest adventure https://github.com/MultiQC/MultiQC/pull/3425)