Very slow run times

[nishanthmerwin]

I've been using unicycler quite a bit over the past few months, and I've gotten really good assemblies out of it. However, I was surprised to notice that the program took a very long time to run. In the original paper, it mentioned ~24 hours, but in my cases, everything took between 3-5 days to complete. I was interested in what was taking so long, so I recorded the times for each of the 33 bacterial assemblies I've done.

By far the most time consuming step was the polishing steps with Pilon and Racon. These are followed by Aligning reads (which I expect to be slow), and then by SPAdes read error correction. One thing that surprised me here was that the spades read error correction takes much longer than the actual SPAdes assemblies.

I'm just wondering if these are patterns that you (or others) have noticed in the past, and whether there is anything we can do to make this pipeline a little quicker?

[rrwick]

Two thoughts jump to mind regarding slow performance:

• thread count
• total amount of reads

If you didn't specify a thread count (with the --threads option), then it should say how many threads it used at the top of the Unicycler output/log. The steps you mentioned as being slow all scale pretty well with threads, so increasing the thread count should help. This obviously only works if your computer has enough CPUs - if you're running Unicycler on a dual-core machine, that may be the problem. If you have access to a larger server, giving Unicycler 20 or so threads will make a huge difference in run times.

Racon will take longer with more long reads, and Pilon will take longer with more short reads, so subsampling your read sets down can make those steps run faster. If either your short read set or long read set exceeds 500 Mbp, that's probably overkill - subsampling will improve speed but probably not impact assembly quality.

I wrote Filtlong for subsampling long reads, so take a look at that tool. For short reads, you could try Trim Galore with stringent settings for --quality and --length. If that's still too many short reads, you might try random subsampling of the reads.

Also, the last Pilon polish is probably the least important step, so you can turn that off with --no_pilon if you'd like faster assemblies. You'll probably have a few more small scale errors (substitutions and indels) in your final assembly, but I wouldn't expect a huge difference.

Let me know if any of these help!

Ryan

[nishanthmerwin]

Awesome, thanks for the suggestions! I ran these with 4 threads each, but it was run on a HPC cluster, so I was favouring having more assemblies run in parallel vs giving one job a ton of CPUs. Actually, do you or anyone else have an analysis of num threads vs total run time? I could probably figure out the optimal number of threads to pass that way.

And yep, did not consider subsampling, I definitely think that could improve run times. Did you ever consider subsampling as a part of the unicycler pipeline?

I don't think I'd remove the polish step, we've noticed that indels make a huge difference in our downstream analysis (gene finding / annotation), so reducing the indels is high priority.

[rrwick]

I have considered integrated Filtlong (or something like it) into Unicycler. If nothing else, I should have Unicycler display a warning/suggestion if the long read set is very large. It's added to my never-ending to-do list 😄

Regarding threads, I'm not aware of any systematic analysis. Since performance rarely scales linearly with threads, I suspect that your approach (4 threads per assembly and many assemblies in parallel) is probably fine. Just keep an eye on memory, as nothing will make a computer slow down like running out of RAM. If memory is tight, then more threads and fewer simultaneous assemblies might be better.

One final thought regarding the Racon polishing time. A little while ago I decided that hybrid assemblies didn't need so many rounds, so I limited it to five. If you're seeing more than five Racon rounds in your hybrid assemblies, that suggests you're using an older version of Unicycler and the current version would be faster.

Ryan