Eland for different sizes

[doxologist]

We are working with sequences that have different lengths... 32, 31, 30 etc in one run. Does anyone know how to run Eland to allow for different lengths or do I have to run multiple times for each specified length?

[seq_GA]

I think the basic criteria for eland is the query sequences should be of same length in the first place.

[doxologist]

thanks... that's what I thought... just wanted to know if someone had a better hackish way of doing different lengths... than what I have now of running it multiple times.

[apfejes]

We used to do that - run multiple times. Back when we ran eland, it used to require a separate compiled version for each sequence length, although that has probably changed in the meantime, so at that point there was no way it could be done.

[doxologist]

so from your answer, you no longer do that?

how do you deal with different lengths now?

currently, we do a combination of multiple Eland runs and Bowtie... but for some things, Eland output is more suited for our needs.

[apfejes]

You're right - we don't do that anymore. We used to do it because the tail end of eland reads was more error prone, so we'd sequentially strip each fragment down by 2 bases at a time, and then take the longest that would align. Now, we use aligners that take the quality into account, and can do more mismatches, so it's really unnecessary.

From my own personal experience with bowtie, I found it to be unreliable - it missed a lot of alignments, and Eland just wasn't flexible enough, so we've mainly moved to maq. (with a few other aligners fitting in to particular roles that they do well.) I understand that the author of maq is now moving to a new aligner (bwa), which uses the same burrows-wheeler algorithm as bowtie, but should be a better implementation. I haven't tried it yet, but you might want to check that out.

As for sequences of different lengths, I think maq should be able to handle those without any fancy tricks. However, if you want to do Eland, my best guess would be to write a parser that separates the reads (and the supporting files, if you use them) into independent files, which each have their own read-length, and then align each one individually. Personally, that sounds like a rather painful way to do it...

Good luck.

[doxologist]

thanks... that's lot of good info.

about the Eland with different lengths... yeah... the parser painful method is what we do now.

the new bwa sounds exciting...
in terms of bowtie missing A LOT of alignments... what do you mean by that?

[apfejes]

in terms of bowtie missing A LOT of alignments... what do you mean by that?

I ran the same input files over the same scaffolds with bowtie and with maq, and got MANY fewer hits with bowtie. It may have had to do with the organism only having a draft reference or something, or the sheer number of scaffolds it had, but whatever it was, the number of hits dropped dramatically.

Anecdotally, I've heard the same thing from other people who've used it as well. I don't want to suggest it's a bad application - it's a giant leap forward in many respects, but I suspect the implementation needs some fine tuning.

[doxologist]

hmm... interesting. I've asked the question at the Bowtie thread... we'll see if other people have similar experiences.

about Bowtie being a huge leap.. no doubt. if imitation is the best compliment... it's getting a large number of compliments... SOAP2, bwa, etc.

[apfejes]

I'll be very interested to hear what people have to say on the issue. I'm a big fan of bowtie, so if it turns out I was just doing something wrong, I'd love to know.

Anthony

[doxologist]

This is what Ben responded:
The circumstances under which Bowtie might miss alignments that are "valid" according to its alignment policy are outlined in the manual (see last paragraph of section "Maq-like Policy"). These misses only occur in -n 2 and -n 3 modes, and they can be avoided by increasing the --maxbts parameter (at the cost of some speed). Unless your read data is very low quality, the fraction of reads missed due to the backtracking limit in -n 2 mode is generally very small (<1%).

Note that when you run 'maq' with -n 2 option (the default), it will find some alignments that actually have 3 mismatches in the seed. Bowtie will *not* report alignments with 3 mismatches in the seed unless -n 3 is specified. It's likely that this is the source of the difference that the anecdotal reports are referring to.

[apfejes]

Thanks - that doesn't seem to describe what I saw, or what was reported to me, but, as I said, it's quite possible that I did something wrong when I used it.

Edit: I should also add that I have been doing a lot of Paired End Tag sequencing lately, which is not yet supported by Bowtie - so there were other reasons for staying with Maq. I don't want to make it sound like this was the only reason we didn't stick with Bowtie.

[doxologist]

I agree... I think the added functionality and versatility are the main reasons that people are sticking with MAQ. I remember reading Heng's comment somewhere that he wanted to emphasize that. I'm excited about how the SAM format would hopefully makes programs more able to talk to each other and more functional.

[apfejes]

I'm also excited about the SAM format, as well, although the prospect of implementing it in Java is quite terrifying - particularly with the claim in the SAMTools manual that explicitly states that Java doesn't support multipart gzip files...

I'm sure it'll be a challenge!

[lh3]

Broad will upload SAMtools Java APIs in a few days.