Repository navigation
Update Wakhan to 0.5.0 - #214
Conversation
No biocontainer was built for 0.5.0, so the module runs ghcr.io/ljwharbers/wakhan:0.5.0, a micromamba image of bioconda::wakhan=0.5.0 built from ljwharbers/Wakhan@container/0.5.0. 0.5.0 rewrote the output tree: each solution is solution_<ploidy>_<purity>_<confidence>/ with integer_profile.*, subclonal_profile.*, genes/genes_copynumber_states.* and a HiScanner_plots_data.zip, and ranked solutions are solution_rank_<n>. The per-solution details plots, variation_plots and loh_regions BEDs are gone. Ten of the old output globs no longer matched, so the outputs, meta.yml and docs/output.md follow the new layout; solution_dirs now takes the rank links only, since solution_* would also catch the real directories. The command line is unchanged; --centromere is spelled out as --centromere-bed. The version now comes from `wakhan --version` (stderr dropped: it carries a pkg_resources deprecation warning), and the stub writes every declared output instead of a lone .bam. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
1.6.1 finds Wakhan's per-solution copy-number plots in the 0.5.0 layout (solution_rank_<n>/integer_profile.html) as well as 0.4.x; 1.6.0 dropped them silently. Only the reported version changes in the snapshots; the module test and the default pipeline test pass on them unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| 'biocontainers/wakhan:0.4.4--pyhdfd78af_0' }" | ||
| // No biocontainer was built for 0.5.0; this image installs bioconda::wakhan=0.5.0 | ||
| // (recipe: https://github.com/ljwharbers/Wakhan/tree/container/0.5.0/container) | ||
| container "ghcr.io/ljwharbers/wakhan:0.5.0" |
There was a problem hiding this comment.
The container directive breaks the repo convention in REVIEW.md in two ways:
- No singularity/docker ternary. Every other module picks a SIF for Singularity/Apptainer and a Docker image otherwise. Here Apptainer users get
docker://ghcr.io/...and convert it on every pull.ext.singularity_pull_docker_containeralso stops having any effect. - ghcr for a large Apptainer image. The SIF is 427 MB. REVIEW.md asks for Docker Hub for large images, and
modules/local/clairsto/main.nfexplains why: ghcr redirects blob downloads to an Azure URL that expires mid-stream, and Apptainer can't resume the download. Wakhan runs on the HPC/Apptainer path, so this is the setup where the pull is most likely to fail.
Suggested fix: push a SIF and a Docker image to Docker Hub and use the usual pair:
| container "ghcr.io/ljwharbers/wakhan:0.5.0" | |
| container "${ workflow.containerEngine in ['singularity', 'apptainer'] && !task.ext.singularity_pull_docker_container ? | |
| 'oras://docker.io/ljwharbers/wakhan-sif:0.5.0' : | |
| 'docker.io/ljwharbers/wakhan:0.5.0' }" |
There was a problem hiding this comment.
Addressed in 9ff6d0c. WAKHAN now uses the same Docker Hub pair as ClairS-TO:
container "${(workflow.containerEngine == 'singularity' || workflow.containerEngine == 'apptainer') && !task.ext.singularity_pull_docker_container
? 'oras://docker.io/ljwharbers/wakhan-sif:0.5.0-histfix-1afd44d'
: 'docker.io/ljwharbers/wakhan:0.5.0-histfix-1afd44d'}"There is still no 0.5.0 biocontainer: quay stops at 0.4.4 and the Galaxy depot returns 404.
The new tag is not a rebuild. Dockerfile.histfix starts from the tested ghcr image by digest (sha256:403a50c8…) and adds one layer with upstream commit 1afd44d4. That commit is the hist_end clamp in update_coverage_hist for KolmogorovLab/Wakhan#64. The IndexError it fixes is still in 0.5.0, at process_bam.py:257, and it killed WAKHAN on several samples in a recent hg38 run. The patch script fails the build unless the unpatched block occurs exactly once.
Checks:
- Fork workflow run:
wakhan --version= 0.5.0, as root and as uid 1001, without the micromamba entrypoint.- The clamp is present at line 257.
- A read ending past the chromosome's last 500-bp bin gives
[0, 1, 1]in both the docker image and the SIF. The unpatched code raises the productionIndexErroron the same input. - SIF is 426 MiB. The anonymous
oras://pull returns the built bytes, and the blob redirect goes to CloudFront with more than 30 minutes left before expiry.
- Mindwell,
-profile apptainer: the WAKHAN module test pulledoras://docker.io/ljwharbers/wakhan-sif:0.5.0-histfix-1afd44dand passed with its snapshot unchanged (versions_wakhanstill reads 0.5.0 from the image). Thedefaultpipeline test also passes on 9ff6d0c, after merging Update nf-core modules and local module tools #212.
| // WARN: Manually update version information as tool does not provide on CLI | ||
| tuple val("${task.process}"), val('wakhan'), val("0.4.4"), topic: versions, emit: versions_wakhan | ||
| // and LRSOMATICREPORT resolves them by rank directory | ||
| tuple val(meta), path("solution_rank_*", type: 'dir') , emit: solution_dirs, optional: true |
There was a problem hiding this comment.
No CI test runs this code path. conf/test.config sets skip_wakhan = true, WAKHAN has no module nf-test, and every LRSOMATICREPORT module test passes [] for wakhan_files. That leaves several things untested:
- the new output globs (none of them is
optional, so one wrong name fails the whole task); - the
--centromere-bedrename; - the
wakhan --versioneval; - whether
solution_rank_*links are captured astype: 'dir', staged underwakhan/*in LRSOMATICREPORT, and resolve back into the siblingsolution_<P_U_C>/directory, which is what the report 1.6.1 fix relies on.
A wrong guess about the layout won't show up in CI.
Please run the Slurm test array or the queued real-data run with Wakhan enabled, and check that the per-solution copy-number plots appear in the HTML report. A stub-based module nf-test tagged small would at least cover the output declarations.
There was a problem hiding this comment.
Partly addressed in 1ae5e77.
- New
modules/local/wakhan/tests/main.nf.test, taggedsmallso PR CI runs it. It is a-stubtest with a paired-shaped input. It asserts that every declared output channel is filled, thatsolution_dirsis a directory namedsolution_rank_1resolving tosolution_2.0_0.8_0.9/withinteger_profile.htmlinside, and it snapshotsversions_wakhan, which the eval reads from the image as0.5.0. The stub now also writessnps_loh_plots/, which it was missing. This covers the output declarations, the eval and the container. It does not prove the globs match what real Wakhan writes, because the stub writes the layout we expect. - Pipeline snapshots: I ran chm13, clair_only, consensus, deep_only and union on Mindwell (Apptainer, Slurm array 11645746). All pass with the snapshots unchanged, so the edits to those five really are only the
lrsomatic_reportversion bump. - Real data (still open): the queued C8 run hasn't reached WAKHAN. Its base run for Update nf-core modules and local module tools #212 fails earlier, at
GERMLINE_CONSENSUS:BCFTOOLS_NORM(Reference allele mismatch at chr3:16902879 .. REF_SEQ:'TGTGC' vs VCF:'TGTGN', a Clair3 record withNin REF). That is a Update nf-core modules and local module tools #212 problem, not a Wakhan one. The real-glob and report-plot check will be posted here once it's fixed.
|
Automated review: 2 findings, both inline on
A human needs to check before merging: run the Slurm test array or a real-data run with Wakhan enabled. Confirm that all the new output globs match, that |
Tagged small, so PR CI runs it. It checks the 0.5.0 output declarations, that solution_rank_1 is captured as a directory resolving to its solution (what LRSOMATICREPORT relies on), and the version read from the image. The stub now also writes snps_loh_plots/, so every declared output exists. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The 0.5.0 image now comes as a Docker Hub pair, oras://docker.io/ljwharbers/wakhan-sif for Singularity/Apptainer and docker.io/ljwharbers/wakhan otherwise, instead of a docker:// pull of the 427 MB ghcr image. ghcr's expiring blob URLs break slow Apptainer pulls (see modules/local/clairsto/main.nf). The new tag, 0.5.0-histfix-1afd44d, is the published 0.5.0 image by digest plus upstream commit 1afd44d4 (KolmogorovLab/Wakhan#64). That commit clamps hist_end in update_coverage_hist, so a read past a chromosome's last 500-bp bin no longer raises the IndexError that killed WAKHAN on some samples. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dev moved WAKHAN to 0.5.0 (IntGenomicsLab#214), whose module no longer has `vcf_files` / `bed_files`: each solution is one `solution_<ploidy>_<purity>_<conf>/` directory with a merged `integer_profile.{bed,vcf}`, and `solution_rank_N` links rank them. With Wakhan on (the default) the pipeline aborted at launch ("No such property: vcf_files" / "bed_files"); CI could not see it because the test profiles skip Wakhan. - Both subworkflows take `WAKHAN.out.solution_dirs` and use `solution_rank_1`: Padfoot gets its `integer_profile.vcf` (same CN1/CN2/COV1 format Padfoot reads), ReConPlot its `integer_profile.bed` plus `solutions_ranks.tsv`. - The wrapper's Wakhan parser reads the merged profile (hp1_/hp2_copynumber_state; unphased copynumber_state too) and keeps the 0.4 layout as a fallback; the module's bed_output relayout is gone. - PADFOOT_ANNOTATION: a fit table without a matching SV/CN pair arrives as a right-only row of the remainder join and crashed the 4-argument closure; both branches now filter on row[1]. - Fixtures regenerated in the 0.5.0 layout (`wakhan/solution_rank_1/integer_profile.{bed,vcf}`, `wakhan/solutions_ranks.tsv`), headers as Wakhan 0.5.0 writes them; the stub tests use ranked solution directories and cover the right-only rows (a sample with ranks but no rank-1 profile, a SAVANA fit table without copy number). - tests/sv_annotation_compose.nf.test (`small`): `-preview` of the test profile with Wakhan, ASCAT, Padfoot and ReConPlot on, so a renamed or removed caller output fails CI at launch. It fails on the previous wiring with exactly the launch error. Checked on a real Wakhan 0.5.0 run of P215003155 (the dev module on the September inputs): both subworkflows run through the real solution_rank_1 link; the ReConPlot CN table and Padfoot's gene table differ from the 0.4-based ones only by Wakhan's own calling changes (a chr8 haplotype swap, 7 segment states on chr12/chr17). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Updates Wakhan 0.4.4 → 0.5.0. Stacked on #212 (base
chore/module-updates), which stopped at 0.4.4 because 0.5.0 had no container and changed its output layout.Container
Bioconda has
wakhan=0.5.0(since 14 Sep), but no BioContainer was ever built (quay stops at 0.4.4). The module runsoras://docker.io/ljwharbers/wakhan-sif:0.5.0-histfix-1afd44dfor Singularity/Apptainer anddocker.io/ljwharbers/wakhan:0.5.0-histfix-1afd44dotherwise. Docker Hub is used rather than ghcr for the expiring-blob-URL reason inmodules/local/clairsto/main.nf. The image is the tested micromamba image ofbioconda::wakhan=0.5.0(ljwharbers/Wakhan@container/0.5.0, digestsha256:403a50c8…) plus one layer with upstream commit 1afd44d4. That commit is the clamp for theupdate_coverage_histIndexError(KolmogorovLab/Wakhan#64), and it is not in any release yet. The image is built, functionally tested and checked anonymously by ljwharbers/Wakhan@container/0.5.0-histfix (run). The SIF is 426 MiB. Switch back to the BioContainer once one exists and upstream has released the fix.Output layout
I worked out the 0.5.0 layout from Wakhan's writer code at both tags. The command line is unchanged.
<P_U_C>/+ linksolution_<n>solution_<P_U_C>/+ linksolution_rank_<n>*_genome_copynumbers_breakpoints{,_subclonal}.{html,pdf}integer_profile.*,subclonal_profile.*bed_output/*_HP_{1,2}.bed,vcf_output/*.vcfinteger_profile.{bed,vcf}(one boundary-aligned table for both haplotypes),subclonal_profile.{bed,vcf}*_genes_genome.*,bed_output/genes_copynumber_states.bedgenes/genes_copynumber_states.{bed,html,pdf}*_genome_copynumbers_details.*,variation_plots/,loh_regions*.bedHiScanner_plots_data.zip(input for the Wakhan web viewer)The heatmap,
solutions_ranks.tsv,coverage_*,phasing_outputandsnps_loh_plotsare unchanged. The module outputs,meta.ymland thewakhansection ofdocs/output.md(already out of date before this PR) follow the new tree.solution_dirsnow takes only thesolution_rank_*links.Also:
wakhan --version, with stderr dropped because it carries apkg_resourcesdeprecation warning.<prefix>.bam.--centromereis spelled out as--centromere-bed.Report
lrsomatic_report v1.6.0 would silently drop the per-solution copy-number plots: it looks for
solution_<n>/…genome_copynumbers_breakpoints.html. Fixed in ljwharbers/lrsomatic_report#31 (accepts both layouts, with tests), released as v1.6.1;LRSOMATICREPORTnow runsghcr.io/ljwharbers/lrsomatic-report:1.6.1/oras://…-sif:1.6.1. Both are public. The recipe sha256 follow-up is ljwharbers/lrsomatic_report#32.Testing
solution_rank_1are produced, and the version readswakhan 0.5.0from the image.prek run --all-filespasses.defaultpipeline test pass on Mindwell (Apptainer). The snapshots change only in the reported version.🤖 Generated with Claude Code