Hey! Now that SAVANA's merged, I wanted to run something else by you: I've built a differential-methylation-at-CpG-islands module and I think it'd be a good fit as an optional step inside lrsomatic itself, alongside modkit. Curious whether you'd be open to it. What it does (standalone Nextflow entry today, -entry DMR_ONLY): 1. DMR_CALLING: takes a treatment/control bedMethyl pair, restricts to CpG islands with real read coverage in both samples (so it never compares real data against absence-of-data), then runs modkit dmr pair for the actual DMR calls and annotates each with its nearest GENCODE gene. 2. DMR_RANK_PROMOTERS: ranks promoter-proximal DMRs. 3. DMR_LOCUS_PLOTS: per-locus plots from bigWig tracks. 4. DMR_REPORT: HTML/PDF report tying it together. It's nf-test covered end to end (calling, ranking, plots, report, and the entry workflow itself) and there's a written-up method (CpG-island restriction logic, modkit dmr pair params) I can send over. Why I think it fits lrsomatic specifically: the input is exactly what modkit_pileup already produces, {tumor,normal}/modkit_pileup/sample.bed.gz, bgzip bedMethyl. DMR_CALLING/DMR_RANK_PROMOTERS could run directly off that with no format changes. The only gap is bigWig for DMR_LOCUS_PLOTS (not needed for calling/ranking, just the plots), that's a small bedMethyl→bigWig conversion step, tools for it are already in our image. One caveat worth flagging up front: this is a differential comparison between two samples, and that's only meaningful when both sides are the same tissue/cell type. In my own data the "normal" is PBMC, not tissue-matched normal, so tumor-vs-PBMC methylation differences would be dominated by cell-type identity, not tumor biology, that comparison isn't valid and shouldn't run by default. In practice, for my case, what I actually want to compare is tumor sample 6 vs tumor sample 1 (two tumor regions from the same patient), not tumor vs normal at all, so the module's "treatment vs control" framing is already more general than "tumor vs normal," and whatever we land on should keep that generality explicit rather than assuming a tumor_bam/normal_bam pairing. (Example in PDF attached). That's actually already how my DMR_ONLY entry is set up, and I think it's the right shape for lrsomatic too: a separate comparisons samplesheet (dmr_comparisons_csv on our side, columns label,treatment_bedmethyl,control_bedmethyl,treatment_bigwig,control_bigwig), decoupled from the main sample sheet, where each row names which two bedMethyl outputs to compare and under what label. That sidesteps the tumor/normal assumption entirely, a row can point at tumor6 vs tumor1, tumor vs tissue-matched normal, or whatever the user actually wants, and there's no default pairing to get wrong. Would this make sense as a new --skip_dmr-style optional module in lrsomatic, built around a comparisons samplesheet like that? Just want your read on where it belongs before I put together a PR.