Question about next step in a de novo bacterial genome assembly

[JodyFranke]

I am trying to de novo assemble a large bacterial genome (~9.2MB) with a high GC content (~67%). We have paired end data from a single miSeq run. Using a couple different combinations of programs (SPAdes and A5) we have been able to assemble our data into contigs (~700-900). Obviously, we have gaps and are very likely missing some regions of the genome as our contigs span ~8.8MB. I am new to genome sequencing and do not want to cut corners. At the same time, I would like to avoid unnecessary costs if possible for this assembly. From what I understand, I see two options:

A. More short read data. We could do an additional miSeq run starting at the library prep stage or using excess DNA saved after the library prep was done. This would provide more short read data, but I am unsure if doing this will only give reads similar to before. Does anyone have experience with this? Is a second run likely to only sequence the same regions as the first time or can we expect to get data on previously unsequenced regions with an additional run?

B. Long-read. This will help join contigs into scaffolds and hopefully a full genome, but we will likely have very low coverage/inaccuracies for those areas of the genome that the miSeq missed.

Any recommendations on if A or B should be sufficient for a genome assembly given where we are at or will both be necessary? Thanks for the help!

[Brian Bushnell]

With low-coverage long read data, you can also correct the long reads with the Illumina reads.

It's unlikely that you are completely missing coverage of 400kbp of your genome. Rather, Illumina reads are too short to resolve many types of repeats, so they tend to get collapsed or broken into tiny contigs short enough that they were ignored for the purpose of statistics. It is unlikely that additional short-read coverage would help you (though in order to best determine that, you'd need to post the coverage distribution of the assembly as a result of mapping).

Currently, we use either exclusively Illumina or exclusively PacBio for microbe assemblies so I don't really know much about the current best state of hybrid assemblies, but assembling a bacteria into 1 perfect contig with pure PacBio is pretty easy. That said, 9.2 Mbp is huge so maybe it would take ~4 Smrt cells for a pure PacBio assembly...

P.S. You can often improve a Spades assembly by preprocessing the Illumina data in various ways (error-correction, read merging, read extension, duplicate removal, quality-filtering, etc), which is certainly the cheapest approach. Though it won't give you a single-contig assembly.

[JodyFranke]

Thanks!

Our output from A5 says we have 460 scaffolds with a median coverage of 38X. The 10th percentile coverage is 20X. Our Spades runs have given a median coverage of 15X when we open files in Bandage. Perhaps we need to do more preprocessing with Spades to get the outputs more consistent between programs. I’m not sure this is the info you asked for about the coverage distribution as a result of mapping.

Unfortuantely, I do not have access to a PacBio system, but there is someone in the department who has done MinION and could help with that. I agree about the hybrid assembly. I have tried to look for a program to do this, but haven’t seen anyone really recommend anything. As I’ve been doing Illumina, and more of the exact same doesn’t sound like it will help, then perhaps a Mate Pair Library would complement what I already have.

[Brian Bushnell]

If you only have 15X coverage, more coverage would definitely help. If you have 38X... maybe. But coverage estimates from alignment are generally more trustworthy than what assemblers report. E.g.:

bbmap.sh in=reads.fq ref=assembly.fa covhist=covhist.txt covstats=covstats.txt ambig=all delcov=f

...then you can plot the histogram in Excel and see how much low-coverage area you have (that assembled).

Long mate libraries are also useful in improving continuity, but can be more expensive and complicated to make. I'm not sure about the details; I've only heard that anecdotally (as in, that's the reason we moved away from long-mate libraries).