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

Fix to issue #82 refering to failed barcode determination error #83

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MarkusHaak
Copy link

Fix to the error message "Error: Porechop could not determine barcode orientation". I analysed the error and found out that the orientation was determined the following way: Each read in the processed fastq file is aligned against every adapter set, where there exist two seperate sets (forward and reverse) for each barcode. For each barcode set, only the best score among all alignments is stored. To determine the orientation, Porechop compares the sum of max scores of all forward sets to the sum of max scores of all reverse sets.
The problem occurs because this strategy, considering only the max scores, is highly dependent on both the read quality and the number of reads per fastq file. By analysing the cases were the error occured I discovered that both orientations of a set, in my case forward and reverse of BC11, had a max score of 100.0, meaning at least one perfectly aligning read.
As a solution to this problem, I changed the determination of orientation to comparing the sum of all scores instead of only the maximum score. This should be much more robust.

Fix to the error message "Error: Porechop could not determine barcode orientation". I analysed the error and found out that the orientation was determined the following way: Each read in the processed fastq file is aligned against every adapter set, where there exist two seperate sets (forward and reverse) for each barcode. For each barcode set, only the best score among all alignments is stored. To determine the orientation, Porechop compares the sum of max scores of all forward sets to the sum of max scores of all reverse sets.
The problem occurs because this strategy, considering only the max scores, is highly dependent on both the read quality and the number of reads per fastq file. By analysing the cases were the error occured I discovered that both orientations of a set, in my case forward and reverse of BC11, had a max score of 100.0, meaning at least one perfectly aligning read.
As a solution to this problem, I changed the determination of orientation to comparing the sum of all scores instead of only the maximum score. This should be much more robust.
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.

1 participant