Skip to content
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

Selection of mapping conditions for low abundance enrichment and targeted sequencing #50

Closed
tchrisboles opened this issue May 18, 2020 · 1 comment
Labels
question Further information is requested

Comments

@tchrisboles
Copy link

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:

  1. If you unblock for single-off, why not unblock for multi-off? Seems more grounds for unblocking in the case of multi-off signal...?.

  2. Why proceed (in all schemes) for no_map and no_seq? What's the rationale?

@mattloose
Copy link
Contributor

Good questions.

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.

@mattloose mattloose added the question Further information is requested label May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants