-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reads not unblocking as expected #372
Comments
Hmm - this is a little concerning - you are correct that it looks as though it is working, but if you are not seeing unblocked reads in the minKNOW GUI something is wrong. Are you running on a bulk file or a live run? We will do some more testing here - our minknow 6.0 branch isn't technically live yet but it should work! |
Just as a sanity check - if you are running playback - could you try:
and not:
|
I have tried it on a playback bulk file and on a live sequencing run - both with the same results unfortunately! I've tried changing the targets (including pointing to a BED file) and it hasn't changed the outcome. Very confused as the basecalling and mapping does seem to be working behind the scenes - just doesn't then reject the reads it should be. |
OK - my apologies for the issues. Would you be able to share the log file from the run with us? |
From a very short test run of a few minutes - |
OK - we think we've identified a bug - will push a fix but please don't try running again on this branch till this is fixed. |
* Made a proper SVG thought i'd just include it here * Remove setting the read_number on the result Add in the correct strand classifications for minknow 6 * Remove Read number from Result and all references to read number * Update target versions for MinKNOW to 6.0.0 - 6.0.0 Explicitly exit if running on MInKNOW 5.X.X * Update vendored read until API to v3.5.2 * Update test for conencted base caller version to work * Pin ont-pybasecall-client-lib at 7.4.12 * Add downgrade to 2024.2.0 to error message * Fix bug in reads not unblocking as expected #372 * change list() to [] * Chunk tracker uses read_id not read_number, update trackers internal variable names * bump version to 2024.3.0 * Fix tests for the new MinKNOW version compatibility Fix tests for the _statistics too not use `read_number` * Bump summarise version to 0.2.7 * Drop incorrect gotcha * Feature/deprecate guppy (#374) * This commit addresses the removal of guppy.py, partial removal of guppy tests, edits to documentation to largely replace guppy with dorado, removes the ont-pyguppy-client-lib and adds a warning to the readme. It also adds some extra classes to the read_until init in targets. * Remove builtin module for guppy * Update FAQ questions to focus dorado as well as Guppy * Change validate caller warning to mention dorado not guppy * Change readme warnings to Focus dorado and minknow breaking changes more Add link/requirement for dorado_basecall_server not guppy_basecall_server * Rename tests to dorado validation tests * Add dorado to mappy-test install target
Hi @shair89 - this is fixed in main, and we will do a release to PyPI this week. |
Hi,
I am running with readfish/minknow6-compatibility alongside Minknow 6.0.8 on a MinION Mk1B.
Everything appears to be working and
unblock-all
works exactly as expected with a nice peak ~400bp.However when using
readfish targets
I get no rejected reads on the Minknow histogram despite the TOML file validating OK and it producing both a log file and a tsv file containing reads which have the decision "unblock". It is also able to output the live.fq and live.paf for the "rejected reads" which look correct - I have double checked andcontrol = false
in the TOML and--dry-run = false
on the command line. It seems like the unblock decisions are not being fed back to MinKnow?I have tried with a few different targets options in the TOML file, all with the same result.
command:
readfish targets --device MNXXXX --log-file readfish_logs.log --toml readfish.toml --experiment-name "test"
TOML:
Example of log as it's "working":
Hopefully I'm doing something simple wrong but any advice would be appreciated!
Thanks,
Steven
The text was updated successfully, but these errors were encountered: