Skip to content

Use FragGeneScanRs as gene predictor instead of FragGeneScan++ - #13

Open
bmesuere wants to merge 2 commits into
phase1/ci-and-test-fixfrom
feature/frag-gene-scan-rs
Open

Use FragGeneScanRs as gene predictor instead of FragGeneScan++#13
bmesuere wants to merge 2 commits into
phase1/ci-and-test-fixfrom
feature/frag-gene-scan-rs

Conversation

@bmesuere

@bmesuere bmesuere commented Aug 18, 2026

Copy link
Copy Markdown
Member

FragGeneScan++ has been archived since 2021. FragGeneScanRs is maintained, faster, and ours.

Two commits: the swap, and the migration messages for people coming from the old setup.

The swap

The only thing in the way was -c, which the scripts passed and FragGeneScanRs does not accept. It only tunes FGS++'s chunked threading, so dropping it costs nothing. FragGeneScanRs also carries its own training data, so -r goes too.

That makes -f simpler: it now takes the binary, or a directory containing it, instead of a directory that had to hold both FGSpp and train. Without -f, setup looks for FragGeneScanRs on the PATH, which is where cargo, conda and the release tarballs all put it.

The setup check also got stricter. It now feeds a real read and requires a prediction to come back, rather than only checking that the binary starts. The old check piped in a single base:

printf '>a\nA' | ./FGSpp -s stdin -o stdout -w 0 -t illumina_10 -c 240

FragGeneScanRs panics on input that short (index out of bounds in viterbi.rs), worth reporting on that repo separately, but a check that only proves the binary starts was not worth much anyway.

Migration messages

Someone following the old instructions would otherwise hit a baffling failure: passing an FGS++ directory to -f makes setup look for FragGeneScanRs inside it, not find it, and report that invoking FragGeneScanRs failed.

  • umgap-setup.sh recognises an FGS++ install, whether -f points at the directory or at the FGSpp binary, and says the predictor changed. A directory holding both binaries still picks FragGeneScanRs without complaining.
  • umgap-analyse.sh does the same for an existing configuration directory. This is the likelier path: anyone who ran the old setup has an FGSpp symlink there and no reason to run setup again, so they would have got a bare "FragGeneScanRs not found" with no hint that anything changed.

Verification

Detection paths: -f as a directory, -f as a binary, found on PATH, and absent. Migration paths: -f old FGS++ directory, -f .../FGSpp, directory containing both binaries, config directory with an old FGSpp symlink, config directory with neither.

End to end on the bundled testdata:

umgap fastq2fasta testdata/A1.fq testdata/A2.fq \
  | FragGeneScanRs -s stdin -o stdout -w 0 -t illumina_10 -p 4 \
  | umgap prot2tryp | umgap filter

175 predictions from the 200 reads, tryptic peptides out the far end. Both scripts pass sh -n.

Note

Split out of #12 on request. That PR keeps the unrelated README corrections; the two touch disjoint parts of the README and merge cleanly in either order, which I verified locally.

FragGeneScan++ has been archived since 2021. FragGeneScanRs is maintained,
faster, and ours.

The only thing standing in the way was the `-c` chunk size option, which the
scripts passed and FragGeneScanRs does not accept. It only tunes FGS++'s
chunked threading, so dropping it costs nothing.

FragGeneScanRs also needs no training data directory, so `-r` is gone too and
`-f` now takes the binary (or a directory holding it) rather than a directory
that must contain both `FGSpp` and `train`. When `-f` is not given, setup
looks for FragGeneScanRs on the PATH, which is where cargo, conda and the
release tarballs all put it.

The setup check now feeds it a real read and requires a prediction to come
back, rather than only checking that the binary starts. The old check passed a
single base, which FragGeneScanRs panics on.

Verified end to end on testdata: fastq2fasta | FragGeneScanRs | prot2tryp |
filter yields 175 predictions from the 200 reads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings August 18, 2026 13:03

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Someone following the old instructions would have hit a confusing failure:
passing an FGS++ directory to -f made the setup look for FragGeneScanRs
inside it, not find it, and report that invoking FragGeneScanRs failed.

umgap-setup now recognises an FGS++ install, whether -f points at the
directory or at the FGSpp binary itself, and says that the predictor changed.
A directory holding both binaries still picks FragGeneScanRs without
complaining.

umgap-analyse does the same for an existing configuration directory, which is
the likelier path: users who already ran the old setup have an FGSpp symlink
there and no reason to run setup again. They now get told why rather than a
bare "FragGeneScanRs not found".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants