Velvet 1.2.10 with FASTQs of different read-lengths AND paired- and single-end?

[Genomics101]

Greetings.

I have been using Velvet 1.2.10 to create de novo assembled contigs with good results using 100bp paired-end reads.

Now I have more and different data, because I have longer reads and because I now trim for quality using Btrim64. As a result, from the two original sets of paired-end reads, 100 and 250bp reads (with 400 and 600 bp insert sizes, respective) I have 4 sets of reads:

Sample1_100bp_R1.fastq.pe
Sample1_100bp_R2.fastq.pe
Sample1_100bp_R1.fastq.se
Sample1_100bp_R2.fastq.se
Sample1_250bp_R1.fastq.pe
Sample1_250bp_R1.fastq.pe
Sample1_250bp_R2.fastq.pe
Sample1_250bp_R1.fastq.se
Sample1_250bp_R2.fastq.se

(The single reads result when the pair is sacrificed in the quality trimming)

I have 3 questions:

Is it possible to combine all of these data for a de novo assembly in Velvet?

Are the 250bp reads still considered short reads or are they long reads?

Is there a problem now that the read-length is no longer consistent due to trimming?

Thanks!

[mastal]

Is it possible to combine all of these data for a de novo assembly in Velvet?

Yes. You may have to recompile velvet to run with a larger number of categories, probably 'CATEGORIES=4' .
You should flag your 2 sets of PE reads as -shortPaired and -shortPaired2, respectively.

Are the 250bp reads still considered short reads or are they long reads?

See the discussion about this in the velvet manual,

https://www.ebi.ac.uk/~zerbino/velvet/Manual.pdf

I think it's probably up to you whether you want to consider them long reads or short reads.

see also this thread in the Velvet mailing list archives:

http://listserver.ebi.ac.uk/pipermail/velvet-users/2012-September/001747.html

Is there a problem now that the read-length is no longer consistent due to trimming?

No.

[Genomics101]

Thanks very much, the Manual for my version of Velvet was unclear about all these points and I very much appreciate your time on this.