Is this true?

[oiiio]

I was going to put this in the 'literature watch' section, but decided to place it here because its more a question about alignment tools.

In the latest online release (April 20) of Genome Research there is "lobSTR: A short tandem repeat profiler for personal genomes". Reading some of the results in this paper are quite interesting...

I attached a screenshot of one of the tables where it does a comparison to other popular read aligners (100bp Illumina).

In the column titled 'indel tolerance(bp)', only BLAT is capable of going past 7 bp indels? Is this true? And i'm assuming that the comparison for bowtie was not bowtie2..

[oiiio]

Here is a link to the full paper

http://genome.cshlp.org/content/early/2012/04/19/gr.135780.111.full.pdf+html?sid=c10866e9-ebe6-491a-af77-1fc846d22e95

[xied75]

The numbers are really interesting. Can't speak for others, but for BWA, I can do 15.8 million human paired-end 90bp reads in 576 seconds real time with 30 threads (-t 30, total CPU time 12000 seconds). The paper's time is bit slow, does that include BWA SAMSE/SAMPE as well?

In BWA ALN, for reads between 93-124, the maxdiff by default is 5, that's the gap number you saw in the table.

Best,

dong

[zee]

This is a fairly old version of novoalign that was used in the comparison. In that older version the gap extension penalty of 15 was much higher than BWA or Bowtie's 5. In our latest versions we have now set it to 6 which is more comparable.
Novoalign will definitely pick up indels greater than 7bp. I have generated indels with novoalign-dedup-Dindel that can go as high as 40bp.

Also, on the speed note it looks like they compared novoalign single-threaded version to their parallel version and likewise for BWA. I have not read the whole paper but I would think they should try apples-to-apples wherever possible.

Regarding that attached table I dont know what "noninformative reads" actually refers to but I think the authors are showing that their tool is best because it finds 0 noninformative reads. On the flip side lobSTR does not report the highest number of "informative" reads.

[dietmar13]

interesting, but

they should use a real competitor for their speed test, not the lame ducks

http://gingeraslab.cshl.edu/STAR/

i've tested RUM, STAR, and Tophat with a RNAseq data-set, followed by DE analyses, and found no major differences between these three aligners concerning DE gene lists, except mapping speed: STAR was by far the fastest...

[adaptivegenome]

It is odd that speed is a major point in the paper. It is a new method for genotyping repeats. My question is whether it produces more accurate alignments (which an ROC plot would reveal) and really whether it produces more accurate genotypes. It was not clear to me that they tested either in the manuscript.

[dvanic]

i've tested RUM, STAR, and Tophat with a RNAseq data-set, followed by DE analyses, and found no major differences between these three aligners concerning DE gene lists, except mapping speed: STAR was by far the fastest...

How were they with alternative isoform detection?
And what do you mean by "no major differences"?

[erlichya]

Confusion

Hi Guys,

I think there is some confusion here. The table was generated using the default parameters of different aligners. The run times of all tools (*including lobSTR*) was determined using a single thread. We also said that in the main text.

So, Zee, for your question, we did compare 'apples to apples'. Next time, please try to make an effort to read the manuscript that you are criticizing.

Will be happy to answer any other question.

Yaniv

[arvid]

Hi Guys,

I think there is some confusion here. The table was generated using the default parameters of different aligners. The run times of all tools (*including lobSTR*) was determined using a single thread. We also said that in the main text.

So, Zee, for your question, we did compare 'apples to apples'. Next time, please try to make an effort to read the manuscript that you are criticizing.

Will be happy to answer any other question.

Yaniv

Hmm, I don't quite agree that comparing speed, sensitivity and accuracy of aligners using their default settings make much sense, when these default settings differ - typically the default parameters are optimized for slightly different tasks. This is a typical 'apples with oranges' situation, IMHO. It would make sense to set similar sensitivity settings on all aligners before comparing anything...

Running in a single thread makes sense for strict algorithm comparison, but doesn't reflect a real usage situation, however. Does lobSTR scale well in parallelization?