[samanta]

My question is this, is this length of time normal for velvetg for assembling such a large dataset or has velvetg just run into a continuous loop and it will never run to completion?

I used to work on velvet several years back, and discussed the code/parameters in our blog many times in those days.

e.g.

http://www.homolog.us/blogs/blog/2012/06/08/an-explanation-of-velvet-parameter-exp_cov/

http://www.homolog.us/blogs/blog/2011/12/06/format-of-velvet-roadmap-file/

http://www.homolog.us/blogs/blog/2012/12/27/more-details-on-velvet-roadmaps-file-based-on-readers-question/

The problem with Velvet (especially velvetg) is that it is not at all optimized for large genomes and the time to get to output can be unpredictable. Moreover, you can trust its contig step, but not its scaffolding. However, the contigs produced by Velvet can be easily done by SOAPdenovo2 or Minia in much less time. For example, with the hardware you are describing, SOAPdenovo2 will give you the output in hours, not days.

I know this is not the answer you asked for and you already mentioned about using other assemblers.

[samanta]

One other question...I've seen some folks say the paired end fastq files need to be merged together into a single file for "shortPaired" use in Velvet...and seen some say that the two paired end files need to be kept separate and let velvet read and coordinate reads. Which one is it? For example if I have files Humulus_lane1_read1_1.fastq and Humulus_lane1_read1_2.fastq, should these two files be merged together or kept separately for velvet to work properly?

In the version I worked on two years back for trying to assemble a large genome (~600MB size), the paired reads needed to be merged into one file.

FASTA Line 1-2 (read1 left)
FASTA Line 3-4 (read1 right)

etc.

The difficulty I faced was that the scaffolds were completely unpredictable based on small changes in input parameters (exp_cov). It is not as if you run everything once, press a button and trust the output.

That led me to move on to other assemblers. Also, I make sure I understand the code/algorithm of any assembler I use.

[samanta]

That's also what I've observed with the previous runs of velvet. The program is still "running" but RAM use and % of processor have remained the same now for several days. Would have thought if it wasn't going to work it would have crashed?

A large part of the work is in removing 'tips' and 'bubbles' and then simplifying the graph. That is when you do not see any input/output.