Tweet
Hi folks,
I'm curious if anyone else has tried to use idba_ud co-assemble longer MiSeq data (2x250) with HiSeq data (2x100)? I've tweaked the source code to accept longer reads from MiSeq and also to increase the allowable maxK up to 250 (which uses lots of memory but increases N50 considerably on my data). I'm catted together interleaved fasta files from my MiSeq and HiSeq runs and am currently running a coassembly on our big memory machine like so:
~/software/idba-1.1.0_hack2/idba-1.1.0/bin/idba_ud -r miseq.hiseq.QC.i.fasta -o hyb.1 --num_threads 8 --min_contig 500 --maxk 250
It recognized the input read length as 100bp - though it should range from shorter than that to 250bp (due to quality trimming, reads are variable length). Will this affect how the algorithm treats variable length reads? Any obvious problems anticipated?
Cheers,
Lizzy
I'm curious if anyone else has tried to use idba_ud co-assemble longer MiSeq data (2x250) with HiSeq data (2x100)? I've tweaked the source code to accept longer reads from MiSeq and also to increase the allowable maxK up to 250 (which uses lots of memory but increases N50 considerably on my data). I'm catted together interleaved fasta files from my MiSeq and HiSeq runs and am currently running a coassembly on our big memory machine like so:
~/software/idba-1.1.0_hack2/idba-1.1.0/bin/idba_ud -r miseq.hiseq.QC.i.fasta -o hyb.1 --num_threads 8 --min_contig 500 --maxk 250
It recognized the input read length as 100bp - though it should range from shorter than that to 250bp (due to quality trimming, reads are variable length). Will this affect how the algorithm treats variable length reads? Any obvious problems anticipated?
Cheers,
Lizzy