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

porechop_abi on oxford nanopore hq (Q20+, Q30+) #18

Open
Ales-ibt opened this issue Nov 9, 2023 · 1 comment
Open

porechop_abi on oxford nanopore hq (Q20+, Q30+) #18

Ales-ibt opened this issue Nov 9, 2023 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@Ales-ibt
Copy link

Ales-ibt commented Nov 9, 2023

Hello there! Thank you for developing this tool, it is amazing. As it finds adapter sequences de novo in the raw-reads, it should work as well with the new generation of Oxford Nanopore high-quality reads, right? Do you think any parameters should be adjusted for this task?

Thanks in advance.

Alejandra.

@qbonenfant
Copy link
Collaborator

Hi,
It is always nice to see our tool appreciated, so thank you.

To be honest, I can not confirm with full confidence that Porechop_ABI will work better on these new reads, as I do not know what (or even if) ONT changed on the adapter side ( I may need a little update on this matter).
If they kept them 'as is ', yes it should be better.

On the parameter side, it would be hard to give a definitive answer without a proper benchmark (I will put that on my TODO list). From experience, i would mainly recommand you increase the k-mer size around 20 / 22 (sound like a reasonable value), maybe higher if you have really good reads.

This should increase the quality and overall precision of the final adapter, as you will allow less potential variation around the expected adapter sequence. (same number of error allowed in each k-mer, but spread out more).

To change the k-mer size, copy the ab_initio.config file, change the 'k' value, and use the '-abc' option with your custom configuration file path.

I would highly recommand you check the resulting adapters before trimming, as this is the longest step.
What you should look for is consistent adapter inference accrosse multiple runs (use options -go to only print the found adapter sequences instead of trimming the whole file each time).

If you go that route, I would be interested with the result.

@qbonenfant qbonenfant added the question Further information is requested label Dec 11, 2023
@qbonenfant qbonenfant self-assigned this Dec 11, 2023
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