fix: ft call-peaks --haps fills the H1/H2 columns - #142
Merged
Merged
Conversation
The flag was parsed on CallPeaksOptions but call_peaks hardcoded haps: false when building the pileup, so no haplotype tracks were made and every H1/H2 column was zero. Closes #140
mrvollger
added a commit
that referenced
this pull request
Sep 18, 2026
Cherry-pick of the CI commit from the closed #137. Without it nothing releases from this branch: the release-plz workflow here still triggers only on pushes to `main`, so merging #142 opened no 0.13.1 release PR. - CI runs on PRs that target `release/**`. - release-plz triggers on pushes to `release/**` and on `workflow_dispatch`. Push events use the pushed branch's workflow file, so this copy only acts on this branch. - cargo-dist is dispatched on the released tag instead of `main`, so binaries build from the patched 0.13.x source. Merging this is itself a push to `release/v0.13`, so release-plz will run and open the `chore: release` PR for 0.13.1 with the #142 fix. Co-authored-by: Mitchell R. Vollger <mvollger@gmail.com>
mrvollger
pushed a commit
that referenced
this pull request
Sep 18, 2026
## 🤖 New release * `fibertools-rs`: 0.13.0 -> 0.13.1 <details><summary><i><b>Changelog</b></i></summary><p> <blockquote> ## [0.13.1](v0.13.0...v0.13.1) - 2026-09-18 ### Fixed - pin hts-sys 2.2.0 and turn off the release-plz semver check ([#148](#148)) - bump vergen-git2 to 9.1 so a fresh resolution builds again ([#146](#146)) - ft call-peaks --haps fills the H1/H2 columns ([#142](#142)) ### Other - put semver_check = false in the [workspace] table ([#150](#150)) - support patch releases from release/** branches ([#143](#143)) </blockquote> </p></details> --- This PR was generated with [release-plz](https://github.com/release-plz/release-plz/). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
mrvollger
added a commit
that referenced
this pull request
Sep 18, 2026
Forward-port to main of the 0.13.1 fix for #140, which shipped from `release/v0.13` in #142. ## Cause `--haps` was parsed on `CallPeaksOptions`, but `call_peaks_for_chrom` hardcoded `haps: false` when it built the pileup. The pileup never made H1/H2 tracks, so every peak printed the empty-track placeholder (`0 0 -1.0 0 0`) for both haplotypes. ## Fix `haps` moves from `CallPeaksOptions` into `PeakCallingParams`, which is what `call_peaks_for_chrom` receives. Both structs are flattened, so the flag name and help text are unchanged; `--haps` now appears among the peak-calling options in `--help` instead of last. union-peaks sets it false because BED intervals carry no HP tag. The second commit keeps `--haps` from costing more than it must. Per-haplotype tracks triple the pileup memory per chromosome, and about a third of that was FIRE element tracking on the H1/H2 tracks that nothing reads (only `all_data.fire_elements` feeds peak boundaries). The haplotype tracks are now built without it. ## Check `NAPA.bam` carries HP tags. `ft call-peaks --haps --min-fire-frac 0.5` on it: | | coverage | coverage_H1 | coverage_H2 | |---|---|---|---| | before | 95 | 0 | 0 | | after | 95 | 45 | 14 | A regression test pins these three values. The call-peaks snapshot and pileup tests pass. ## Order Merge into main after #149 and before #138. release-plz opens the 0.14.0 release PR on the first push to main after #149. Fixes #140 --------- Co-authored-by: Mitchell R. Vollger <mvollger@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #140.
ft call-peaks --hapsprinted zero for every H1/H2 column on a haplotagged BAM, whileft pileup --hapson the same BAM was correct.Cause
--hapswas parsed onCallPeaksOptions, butcall_peakshardcodedhaps: falsewhen it built the pileup. The pileup never made H1/H2 tracks, so every peak printed the empty-track placeholder (0 0 -1.0 0 0) for both haplotypes.Fix
Pass
opts.hapsthrough. One line.Check
NAPA.bamcarries HP tags.ft call-peaks --haps --min-fire-frac 0.5on it:A regression test pins these three values.
Patch release (0.13.1)
Targets
release/v0.13so it ships in 0.13.1. Forward-port to main is #141.