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

WARNING: iterations are disabled #15

Closed
Phylloxera opened this issue Jun 21, 2019 · 4 comments
Closed

WARNING: iterations are disabled #15

Phylloxera opened this issue Jun 21, 2019 · 4 comments

Comments

@Phylloxera
Copy link

Hello,

I saw in issue #11 that iterations are disabled by default for single-end data. I've also observed that this seems to be hard coded, ie. even when I specify --steps 11, I still get 'WARNING: iterations are disabled'. It seems skesa should be more powerful for single-end data (return fewer contigs) if run at multiple kmers... am I missing something important theoretically by thinking this?
Thanks!

@souvorov
Copy link
Collaborator

Hi Phylloxera,
Iterations with kmers up to the read length are not disabled for single-end data. This warning is usually a result of very short reads or low coverage. Could you please describe what kind of reads you use and upload the log file?

Alex

@Phylloxera
Copy link
Author

Hi Alex,
Sorry it took so long to respond, I was on vacation. Thanks for checking on this; maybe it is a low coverage case but read length should not be an issue. This was really just a test set of reads to see what would happen... They were originally miseq paired-end reads which assemble quite nicely with skesa but for the single end test, I conservatively merged the pairs with bbmerge and ended up with a merge rate of ~50% and ~94K reads. I could not find a log file or an option with skesa -h that would create one. Here is the console output.
single_end_console_output.txt
Thanks again!

@souvorov
Copy link
Collaborator

souvorov commented Jul 9, 2019

Yes, it is a low coverage issue - you lost many reads after bbmerge. From the log you uploaded you can see that the average coverage is 8.86528. It is supposed to be > 10 for the default parameters. You can try --max_kmer_count 5 or lower, and you'll probably get some results.

I'll be surprised if premerging paired reads will be more efficient than allowing skesa to do it internally.

@Phylloxera
Copy link
Author

Good to know about the coverage count cut-off, it makes intuitive sense. And also the max_kmer_count 'fix', I'll try it! Skesa works really well on my paired-end single cell genomes with adequate coverage. The test was more thinking whether it might also be useful for single-end, metagenome, and 'dirty' viral samples in the future.

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

No branches or pull requests

2 participants