You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are three actions that you can take on receiving signal in our code - unblock is obvious - it will reject the read. Stop receiving and proceed are slightly different. Stop receiving says you want no more information about a read and lets it carry on sequencing. Proceed says - send me another chunk of data so I can refine my view.
These options are then over ridden by the max chunks setting which, if a decision hasn't ben made - will unblock a read after a certain number of chunks anyway.
You are perhaps right that a multi-off might as well be unblocked. We were concerned about short spurious matches in repetitive regions that may be of interest later. I think that category could be switched to unblock without a negative consequence.
The proceed for no seq and no map is effectively saying give me some more data to see if I can work out what this read is. We find a lot of reads require more than one chunk (at 0.4s) of data to do something useful. There are all sorts of arguments here for the best course of action and I remain on the fence as to if its better to just throw reads away after one chunk or not. Ultimately this also gets over ridden by the max chunks option. So if a read hasn't provided any usable information after that it will be thrown away (depending on the settings in the code).
no_seq almost never happens now - this is a hangover from early testing of the code where we didn't always get a result back from guppy. After some troubleshooting we realised this was our error - not guppies - and were able to fix. So you shouldn't see no_seq ever.
The mapping conditions listed in your paper for these two goals are similar
multi-on: stop receiving
multi-off: proceed
single-on: stop receiving
single-off: unblock
no_map: proceed
no_seq: proceed
Two questions:
If you unblock for single-off, why not unblock for multi-off? Seems more grounds for unblocking in the case of multi-off signal...?.
Why proceed (in all schemes) for no_map and no_seq? What's the rationale?
The text was updated successfully, but these errors were encountered: