-
Notifications
You must be signed in to change notification settings - Fork 9
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
Expand post blast recovery #21
Conversation
The first release with this must be a new MAJOR release, as it changes the API for recovery scripts.
1. Create new test data set that can better deomonstrate the BLAST filter 2. Create new test reference / blastDB to match new test dataset 3. Add gitignore rule to ignore user-generated recovery scripts 4. Fix recovery scripts for recoverAll, recoverAmbig, and recoverWrongSpecies 5. Remove chrM_recovery, which is a custom recovery script from our lab 6. Add extra tests to the test config file Next commit will be a substantial restructuring of the retrieveSummary script to make it compatible with runing multiple parameters for the same sample.
And do code cleanup.
NOTE: New Bug: There seems to be a plotting issue in the Depth per Target plot where zero-depth positions are not represented as being zero depth.
Take 1
Take 2
Hotfix for expand_post_blast_recover
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to remove the ChrM_recovery script. It's somewhat unique for the mouse mtDNA, plus it assumes a chr__ naming scheme which isn't universal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change back to pure png rendering or do you want to under these changes after this release. I'm fine with either, but since we're still in the dev cycle, it may be worth doing now. Up to you.
I'm trying to be better about only making one set of changes in each branch, but we could do that. |
My main concern is: that change is unrelated to the primary purpose of this branch. |
That's a good point. It doesn't change functionality, just the complexity of the code, so lower priority. Let's get this out and merge in a fix later. |
I have one more branch I want to finish before we go to v2.0.0. Actually, if we're going to do a v1.1.0 release, we should do that before we finish merging this branch. |
This will expand options for post-blast recovery, and will clarify some related outputs.