Hi Monica,

I think what you've changed is the length of the input sequences, not the k-mer length. You would want to add -maxk 200 (but I'm not sure that will be allowed as I think max might be 124). Default is to do from 20-100 at steps of 20. I've inserted the idba_ud flags for this -

--mink arg (=20) minimum k value (

@Artemis Louyakis

Hi Artemis

Thank you for the reply. According to the search in google, we can change the kmer value to the max. I changed my kmer value along with the length. My idba_ud flags after changing the value shows:

--mink arg (=20) minimum k value (

Hi Monica,

Can you post your command exactly how you are trying to run it? It would be more helpful in giving advice.

Artemis

Hi Monica,

If you haven't done so yet, do have a look at the google forums page for IDBA_UD named hku_idba (https://groups.google.com/forum/#!forum/hku-idba). The developers are pretty active there and odds are someone has already asked the question you are thinking about.

On the same page, quoting below what someone named Theo Allnutt wrote about solving the kmer problem:

"Hi,

I've started a new thread for this in case anyone wants to do the same thing. I wanted idba_ud to run with larger kmers. It seems to work pretty well.

I changed /idba-1.1.2/src/sequence/short_sequence.h to longer kMaxShortSequence to:

static const uint32_t kMaxShortSequence = 500;

and changed the max kmer size in idba-1.1.2/src/basic/kmer.h byt changing the number of bits to:

static const uint32_t kNumUint64 = 16;

Then recompiled:

./configure make

Now IDBA is working with my 300 bp paired end illumina data with kmers of 100, 200 and 300. Assembly looks much better so far than it was with kmers limited to 124 bp. I don't really understand why assemblers limit kmer size, but I'm not a mathematician. The highest kmer size always seems to give the 'best' assembly. If you run into a memory problem it might be worth limiting the number of threads used, although I haven't tested this, when I use fewer than maximum, it works."