[Brian Bushnell]

The main peak is still below 10x, which will make assembly very fragmented. But this data looks a lot better than the normalized data. I don't know which normalizer you used, or what settings, but the output came out very strange - I would expect the raw reads to give a better assembly than the normalized ones.

[morning latte]

Thank you Brian. I appreciate for your all advices.

I have the last question. I am not still clear how you interpret the kmer frequency histogram. Could you explain a bit more on how to interpret the histogram? Thank you.

[Brian Bushnell]

The kmer frequency histogram tells you the depth of coverage of the target genome. This is more complicated in a metagenome, but if you have a single bacterial genome with no repeats, then with very even coverage, you would get a single peak in your graph. With repeat content, there will be additional higher peaks. You get the best assembly when this primary peak is narrow and above some minimum depth. Velvet does well when the primary peak is around 30x to 40x coverage (that's the X axis).

If most of your kmers occur fewer than 10 times or so, you can't assemble them very well.

[AndrewRGross]

First off, I discovered that I'd counted my initial reads wrong, so my .sam file has the right number of reads afterall.

Instead of bowtie, I tried mapping with bbmap. On my first attempt, I reduced the percentage of unmapped reads from 50% to 29%. I'm planning on running bbmap again with a more sensitive set of input parameters.

Annoyingly, this recent sam file produced a bam file which samtools' index command seems unable to index. It keeps stopping and outputting "Killed".

[Brian Bushnell]

Instead of bowtie, I tried mapping with bbmap. On my first attempt, I reduced the percentage of unmapped reads from 50% to 29%. I'm planning on running bbmap again with a more sensitive set of input parameters.

Annoyingly, this recent sam file produced a bam file which samtools' index command seems unable to index. It keeps stopping and outputting "Killed".

The bam format does not really allow files with more than 2GB of header data. I don't know if that's the problem in your case, but if you do have millions of contigs, it's a possibility. You can often get around it by filtering out the contigs shorter than a certain length, which are often kind of useless anyway. I think the latest version of samtools is fixed to allow larger headers, but there's no assurance that downstream tools will be able to process the bam.

If you want to run bbmap with greater sensitivity, you can use the "slow" flag, and reduce the "minratio". The default is "minratio=0.56", which allows mappings with scores down to 56% of the max. Also, if you want to map really low quality reads, you can set "qtrim=rl trimq=10 untrim". This will quality-trim reads to q10 before mapping, then undo the trimming after mapping (trimmed bases will be soft-clipped). The "local" flag will also slightly improve mapping rates by doing local rather than global alignments.

[dpryan]

A message of "killed" usually means that the OS killed it (often due to using all the memory). You might go through the system logs and see if those tell you what went wrong.