-
Notifications
You must be signed in to change notification settings - Fork 21
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
QUESTION: What's the largest genome that end-users have assembled with RAVEN? #36
Comments
Here is the preprint: https://www.biorxiv.org/content/10.1101/2020.08.07.242461v1. Although, the version in the benchmark is 1.1.10, and versions 1.3.0 and upwards use far less memory. We should update the preprint soon. Answers:
|
Okay, we just did a 6.0 Gbp beastie; but RAVEN gave us just over 7.0 Gbp. Took five days, 2 TB ECC RAM; 124 threads; two CUDAS (RTX TITANS used for polishing; -c=100) Given that the assembly is a little large, I'm wondering if I should change any of these three parameters, and whether or not you'd have some recommendations?
|
Also, would increasing the rounds of polishing (RACON) drastically improve the assembly? |
Okay - got 0.1% Complete with a BUSCO analysis. Something is wrong, would you suggest increasing the penalty for the mismatch score? |
Can you print the assembly statistics (length/#contigs/NX/NGX)? Which sequencing technology are you using? What is the sequencing depth? The BUSCO score is abysmal, not sure if changing alignment parameters will help. Running more than 2 iterations of Racon will not increase the accuracy by much either. Sorry for my late reply! P.S. You can also paste here the log Raven created. |
Technology is PacBioSII CLR with the N50 of the raw reads >36Kbp. The coverage is about 70x. Q: Would adjusting the -m, -n, -g parameters improve assembly? What file is the RAVEN logfile? Here's the QUAST analysis; the # of contigs is good-ish, but the N50 isn't the greatest:
|
The log is outputed to stderr. I am not sure if changing alignment parameters will help at all. The assembly is quite fragmented which might be the reason for bad BUSCO performance. |
The text was updated successfully, but these errors were encountered: