Velvet 1.2.10: why the big difference in results with -long vs -short w/ 250bp reads?

[Genomics101]

Greetings.

I am doing some de novo assembly of a 23 Mb genome using MiSeq paired end Illumina reads (250bp reads, 400bp insert (SD 130)). These reads, however, have been trimmed for quality and range widely in their finished size, with most at about 190bp. Assembly using -long/-longPaired vs -short/shortPaired gives surprisingly different final results. Any ideas why this is happening or which results are more reliable?

Thanks!

Commands:

velveth Genome1_71 71 -short -fastq reads_R1.trimmed.fastq.se reads_R2.trimmed.fastq.se  -shortPaired -separate -fastq reads_R1.trimmed.fastq.pe reads_R2.trimmed.fastq.pe
velvetg Genome1_71 -exp_cov 43 -ins_length 407 -ins_length_sd 130

velveth Genome1_71 71 -long -fastq reads_R1.trimmed.fastq.se reads_R2.trimmed.fastq.se  -longPaired -separate -fastq reads_R1.trimmed.fastq.pe reads_R2.trimmed.fastq.pe
velvetg Genome1_71 -exp_cov 43 -ins_length_long 407 -ins_length_long_sd 130

Results, short:

Final graph has 128642 nodes and n50 of 17324, max 332339, total 26267561, using 6042595/7501247 reads

Results, long:

Final graph has 148426 nodes and n50 of 1610, max 28675, total 26984545, using 6083488/7501247 reads

[ctseto]

Zerbino tells us there shouldn't be any difference, but what you've found is interesting.

Have you tried this without the singletons and just the paired reads?

It's interesting that your -long flag increases read utilization and subsequently affects your n50. It's breaking up your reads since you've lost fragments larger than 28675...

Does that 28675 fragment exist in your -short assembly?