How can be possible? (Velvet)

[aloliveira]

I provide 5 reads to velvet (one read with 600 bp in size and the other four with 70 bp). After running , velvet returns an assembly with one contig with 572 bp in size. How can be possible an assembler returns a contig smaller than one of the reads???

Best regards,
André

[Torst]

I provide 5 reads to velvet (one read with 600 bp in size and the other four with 70 bp). After running , velvet returns an assembly with one contig with 572 bp in size. How can be possible an assembler returns a contig smaller than one of the reads???

What was the command line you used to run Velvet?

(It's an artifact of your low coverage, and edge-effects of k-mers)

[A_Morozov]

May I ask a noobish question? Is it 5 reads as in "Five pieces of DNA sequence being read by some method" and if yes, how did you end up assembling it? No insult meant, I'm really curious.

[Torst]

May I ask a noobish question? Is it 5 reads as in "Five pieces of DNA sequence being read by some method" and if yes, how did you end up assembling it? No insult meant, I'm really curious.

I think the user is just testing Velvet, and is wondering why, if they feed it 5 sequences, one of which is 600bp, why do they get a final contig out that is shorter than 600bp. ie. what happened to the other 28bp.

[boetsie]

Have you looked at the final contig and see which part is missing? Does any of your other four sequences contain a nearly similar sequence (e.g. one bp difference) than the missing part. Velvet uses k-mers (provided by the option 'hash_length' with velveth), if you have a k-mer that is near identical, the assembler does not know which path to choose. Example;

GATAGAGTAGAGA
GATAGAGTAGAGT

The assembler does not know if it should choose the A or T here. Look at the last x bases (where x depends on the set k-mer) of your contig, and see if any of the other four reads contains this k-mer.

Regards,
Boetsie