memory requirments of velvet tool (de novo assembly)

[bioinfosm]

Hi,

Does someone have an idea of how much memory would velvet require for a given input of short reads? And how would it possibly scale with more / longer reads?

Also, any other 'large dataset' de novo assembly tools for the illumina reads. SOAP says 100Gb RAM for human sized genomes, are there other options and what would their memory requirements be?

thanks for sharing..

[bioinfosm]

To answer part of it myself, this is a useful source on velvet mailing-list

http://listserver.ebi.ac.uk/pipermail/velvet-users/2009-June/000359.html

The gist is,
Ram required for velvetg = -109635 + 18977*ReadSize + 86326*GenomeSize + 233353*NumReads - 51092*K

Gives the answer in kb.

Read size is in bases.
Genome size is in millions of bases (Mb)
Number of reads is in millions
K is the kmer hash value used in velveth

[Torst]

The above formula derived by Simon Gladman has a caveat of only being applicable to Velvet when compiled with the default MAXKMERSIZE=31. If you compiled with 63 for example, the memory usage will increase.

[KevinLam]

So what happens when the machine doesn't have enough ram?
does it give a error or just proceed very very slowly?

would having a large enough swap partition help?

[Zigster]

It will segfault, but sometimes it will lock up a machine so badly you will have to physically pull the plug.

I suggest using ulimit, for example I have a 256gb machine and use
ulimit -v 240000000
before every run

[jgibbons1]

We've been needing approximately 30g of RAM for velvet assembly with a minimum of 24g depending on the kmer length specified. *This is with single-ended read 36bp Illumina data.

[francesco.vezzi]

In order to assmebly a lane of paired reads of length 75 we used 120 giga with a k-mer size of 47.
Obviously the amount of date decrease with a smaller k-mer, but a shorter k-mer implies a higher possibility of mistakes.

I think, this is a my opinion, that with the increasing of the read length tools like velvet will became too memory consuming, and they will became unpractical.
With a read length of 150 an approach like PCAP, ARACNE and EDENA that build an overlap graph and not a de bruijn graph is the only feasible opportunity

[bioinfosm]

Is it human genome you are working on

One approach is to map reads to reference, and assemble the unmapped reads. Though this can yield a pretty fragmented assembly that is hard to use eventually...

Do you usually do things like remove contaminants or low quality reads, take only the unique set of reads.. ? These can certainly reduce the run time, but last I looked, using a redundant set of reads gave slightly different assembly than a non-redundant one.

[jgibbons1]

Sorry...I replied to the wrong thread.

[nxtgenkid10]

how to regulate velevt memory cosumption

I m using velevet for assembly and velevtg is consuming aroung 90% of my memeory ...is there any ways where in i can control the same ... say by threading or any other step?

[jgibbons1]

I've found that one of the best ways to reduce the memory requirements is to quality filter your read set before assembly. Low quality reads directly impact memory. Trimmomatic and Quake are both very good for quality filtering.

[jjjscuedu]

velvet memory problem

Hi all,

I have tried to use the velvet for my RNAseq data assembly.

My machine is about 40G RAM.

The read length is about 101 for my dataset. The total number reads is about 60 million for one file of pair end. The total size is about 120 million.

However, when I try to assembly it, and when it run after GHost threads and begin to threading through reads. I find it has occupied about 65% RAM. Hence, I need to stop it.

Can anyone give me some suggestions about how to reduce the memory usage? I have set the Kmer to 75 for my dataset.

Jingjing

[arvid]

1. Get a machine with more RAM
2. Use shorter k-mers
3. Try to reduce complexity in your reads by using Quake or something similar
4. Subsample your reads
5. Use a different assembler

Velvet is known to be memory-hungry, therefore 1 is the best choice. However, if this isn't an option, you should at least try 2 (75 sounds very, very high) or 3, with 4 as the last resort - unless you want to try a completely different assembler. CLC is very memory efficient but commercial...