velvet, Destroying splay table

[tatianaliu]

hello, dear all.
I have a question about velvet, after runing velveth, it stopped and shows


Inputting sequences...
Inputting sequence 0 / 622511
Done inputting sequences
Destroying splay table
Splay table destroyed

but the splay files are ok in src
what's this meaning?
Thaks in advance!

[tatianaliu]

dose anybody how that?

[OTU]

I have the same error!
Anybody knows the decision?

[SES]

I don't think this is an error. As I recall, this is the final thing velveth always prints before it finishes.

[OTU]

Ok, Thanks!

So, then, when I ran velvetg on the output info, I got at the end an empty velvet_asm.afg file.
What can be the reason for this?

[SES]

Ok, Thanks!

So, then, when I ran velvetg on the output info, I got at the end an empty velvet_asm.afg file.
What can be the reason for this?

It is difficult to say, we will probably have to see the commands to try and figure out what went wrong. I can try to locate some velvet logs and see if this message is indeed expected.

[mastal]

As mentioned by SES, 'Destroying splay table' is not an error message,
it is one of the normal lines of output you get from velvet as it is completing a run.

Velveth should produce 3 files if it runs successfully - Log, Roadmaps, and Sequences.

If your .afg file is empty, it may be that your assembly didn't produce any contigs longer than the default cutoff size.

If the .afg file is empty, is the contigs.fa file also empty?

What are the commands you used to run velveth and velvetg, and what is the last line in the Log file (this has the assembly metrics) after running velvetg?

[OTU]

Ok, so the contigs.fa is 11 Mb.
The commands for velveth and velvetg were:
/velveth velvetTM7 31 -shortPaired -fastq /home/annet/Sdata/merged8.fastq \
< /home/annet/Sdata/merged8.fastq ;

/velvetg velvetTM7 -exp_cov auto -cov_cutoff auto -read_trkg yes -amos_file yes \

[OTU]

And the last line of the Log file was:


Median coverage depth = 1.036364
Final graph has 548010 nodes and n50 of 47, max 3601, total 9364237, using 503532/1832674 reads

Eah, seems like N50 is really tooo small

[swbarnes2]

Yes, the others are right...Velvet ran with no errors, but it failed to build contigs.

So either your coverage is way too low, or your reads are very error prone, or you've got some kind of artifact messing things up.

On thing I like to do to troubleshoot is to look at what are the most abundant reads. You can do that with samtools and unix commands:

samtools view mybam.bam | cut -f 10 | sort | uniq -c | sort -nr > read_count.txt

It's a reality check of what's really in your samples. So if your sample is really full of adaptor, or some other kind of artifact, you are likely to see that.

[OTU]

Hm....
But there are no .bam files to run on samtools...
Do I need to proceed my reads on other program prior?