Transcriptome assembler versus genome assemblers

[samanta]

In these pair of posts, I discussed de Bruijn graphs and explained why short read genome assemblers (Velvet, etc.) do not work well for transcriptome assemblers.

http://www.homolog.us/blogs/?p=123

http://www.homolog.us/blogs/?p=158

I presume the above topics are piece of cake for most of you, but those hapless few, who don't work on algorithms, may find them useful.

Please feel free to comment here, there or anywhere

[savkart]

I found this post extremely useful! Thanks!

[kopi-o]

Great posts! Looking forward to the next one already.

[samanta]

Thank you folks !!

[johnwu]

Great articles! I really enjoy reading them. They're really useful!

[samanta]

Great posts! Looking forward to the next one already.

Thank you all for encouragement !!

Next installment on the de Bruijin graph series here -

http://www.homolog.us/blogs/?p=171

Please let me know, if anything is unclear or incorrect.

[masterpiece]

multiple K-mers could be the answer??

great post here, thanks for sharing.

I agree with you, transcriptome assembly using de brujin graph (like velvet, soapdenova) cannot be treated same like genomic assembly. As stated in this paper, (Surget-groba, Y., & Montoya-burgos, J. I. (2010). Optimization of de novo transcriptome assembly from next-generation sequencing data. Genome Research, 1432-1440. doi: 10.1101/gr.103846.109.2008.) higher K-mers is targeted to highly express gene and lower Kmers will better assemble for lowly express gene. Therefore using 1 Kmer size will not cover the whole transcriptome. In this paper they suggested multiple K-mers to tackle both higly express and lowly express genes. Personally I prefer Subtractive Multiple-k rather than the Additive Multiple-k method

And the new Oases, as an extension from velvet, can handles the uneven coverage of contigs due to variation in expression levels of the transcripts in the sample.

I believed with this development, short-read assembler program is still relevant for transcriptome assembly



kamal

[samanta]

great post here, thanks for sharing.

I agree with you, transcriptome assembly using de brujin graph (like velvet, soapdenova) cannot be treated same like genomic assembly. As stated in this paper, (Surget-groba, Y., & Montoya-burgos, J. I. (2010). Optimization of de novo transcriptome assembly from next-generation sequencing data. Genome Research, 1432-1440. doi: 10.1101/gr.103846.109.2008.) higher K-mers is targeted to highly express gene and lower Kmers will better assemble for lowly express gene. Therefore using 1 Kmer size will not cover the whole transcriptome. In this paper they suggested multiple K-mers to tackle both higly express and lowly express genes. Personally I prefer Subtractive Multiple-k rather than the Additive Multiple-k method

And the new Oases, as an extension from velvet, can handles the uneven coverage of contigs due to variation in expression levels of the transcripts in the sample.

I believed with this development, short-read assembler program is still relevant for transcriptome assembly

kamal

Thank you for your comment. I agree with what you said.

My article was written for introductory users to explain the difference between genome assemblers (Velvet) and transcriptome assemblers (Oases).............just to make sure people use right tools for right data. You are already an expert in that regard.

[vbiaudet]

count read

I agree with the last both thread about transcriptom analyses. We also used Oases with different decreasing k-mer to analyse RNAseq and the results seems good (to verify it we get the complete genome and we have mapped the contigs on it, 95% sucessful) The problem is how to count the reads used to construct the contigs... because it's not clear it gives different number by k-mer but no number at the end. Is-it possible to obatin the count reads used with oases?

Thank you for your answer, vb

[rskr]

The article only applies to assemblers which make assumptions about coverage, like Velvet. Many assemblers which are more accurate than Velvet don't make such assumptions so as to avoid issues such as GC bias, or PCR duplicates.