Re: [Inchworm-users] Max Kmer size

[Brian J H. <bh...@br...>]

Hi Greg,

I've responded to your questions below:

On Fri, Feb 25, 2011 at 12:23 PM, Greg Concepcion <gco...@gm...>wrote:

> Hi Brian,
>
> Thanks for the awesome resource!
>
> I've been using the previous version of inchworm (inchworm_01-20-2011<http://sourceforge.net/projects/inchworm/files/OLD_VERSIONS/inchworm_01-20-2011.tgz/download>)
> for de novo assembly of transcriptomic data from a non-model organism with
> no reference genome available. So far my success has been great, both in
> terms of transcript length and maximum memory requirements (which crippled
> my Velvet/Oases assembly)
>
>
Excellent news!



> My strategy so far has been to run inchworm on the raw data with a range of
> Kmer sizes, from 25-37, concatenate those outputs and reassemble using the
> '--reassembleIworm' option.
> This brings me to my two questions so far:
> 1. I had to modify the source to allow a max Kmer size >31. Is there a
> particular reason for this limit?
>

The true maximal limit should be 32, since the kmers are stored as 64 bit
unsigned integers (with 2 bits per base encoding).  I made the max 31
because I was hoping to reserve the last couple of bits to store additional
info at some point... but I haven't used it.   If you try to go beyond 32,
your still only storing a 32mer worth of sequence and tossing out the other
bits.   A different storage strategy would need to be built into inchworm to
go higher than the 32 bits and require some serious reengineering.   In my
various tests, I've found that 25mers work very well for transcriptome data
and going higher (such as beyond 29mers) can end up fragmenting some
otherwise nice full-length transcripts.   Also, the strategy of assembling
using a bunch of different kmer lengths and combining the data (which I
borrowed conceptually from trans-ABySS though it works very differently
here, doesn't buy much, at least in the various tests I've done.  In many
cases, we end up getting an ever so slight increase in the number of
full-length transcripts.


> 2. I doubt the strategy i'm using is "the best" one, however from one lane
> of a flow cell (~5 Gb raw illumina data (2x76bp * 34E06 reads)) I was able
> to generate ~120 Mb of consensus sequence representing >500,000
> contigs/transcripts (above a 100bp threshold). Should I be doing anything
> differently to maximize Inchworm's potential to assemble transcripts? So far
> the lengths are pretty good, with >8,000 transcripts longer than 1,000bps,
> and a few in the 10,000bp range.
>
>
Is this strand-specific data?

Note, I made some important improvements to inchworm recently: both removing
error-containing kmers and adjustments for non-strand-specific data.  I
definitely encourage you to give it a whirl.. just run it once with the
default settings (k=25) and see how it looks.  The total number of contigs
(and amount of complete garbage that result) should be minimal, and the
contigs that are reported should be heavily enriched for quality assemblies.

Also note, I'm hoping to release the full Trinity package sometime next week
(http://trinityrnaseq.sf.net) which takes Inchworm results to another level
of utility, especially where alternative splicing is concerned.


Best,

-brian



> Also, I'm hoping to submit this data for publication in the near future, is
> there an ETA on a date for a publication that I can cite?
>
> Aloha!
>
> Gregory T. Concepcion, PhD
> Cell Biology and Molecular Genetics
> 2107 Biosciences Research Building
> University of Maryland
> College Park, MD 20742
>
> w:301.405.8300
> c:301.828.8210
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Inchworm-users mailing list
> Inc...@li...
> https://lists.sourceforge.net/lists/listinfo/inchworm-users
>
>


-- 
-- 
Brian J. Haas
Manager, Bioinformatics Outreach, Genome Annotation and Analysis
The Broad Institute
http://broad.mit.edu/~bhaas