This is a question that is often asked when I demo the GenomeQuest platform to potential customers. I always answer that question in three phases.

The first phase goes like this: “It’s really fast, it’s certainly not any slower than BWA/Bowtie or anything else out there.”. Next question is always: “Well, do you have any benchmarks?”.

Which nicely transitions me into the second phase of the answer. This phase is much more rigorous and usually starts with: “Well, it depends. Let me try to explain.”:

• Any good computer scientist can write a mapping algorithm that is really fast. However, that doesn’t mean anything unless it produces the kind of results that are needed. The NGS application you’re working with matters here. For example, finding genetic variation in human disease requires very accurate mapping with mismatches and indels. In contrast, with digital gene expression in maize you can cut a lot of corners. You just need to have a rough idea of the number of alignments on a transcript.
• Then there is the matter of the data and the technology that produced it. Do you have long reads (more than 120 bp)? Will your mapper handle them? Will it also increase the number of mismatches / indels it can use to align a read? Will it significantly slow down execution, or eat up all your memory when reads get longer? Does this mapper also support local alignments when you need them? Will it align in colorspace? In paired end mode? I could go on.
• Next there is the matter of connecting results to the following step in your pipeline. How long does it take to de-duplicate a  1TB alignment file in SAM/BAM format? Or to find those alignments who’s position overlaps with your exome capture experiment, or all dbSNP entries? At GenomeQuest we have a very efficient way of storing and handling alignments (including sequences/annotation). This saves real time, especially when compared to the alignment step itself (it saves a lot of disk space as well by the way).

By the time we get to the third phase of the answer I’m usually much more confident: “Well, how fast do you need our mapping algorithm to be?”.

• Does it really matter how fast the read mapper is, as long as it’s comparable in performance to other algorithms for most common use cases? Does it matter if you have the alignments in 2.5 hours instead of 3? Maybe if you analyze thousands of samples per week it matters, but then other things like reliability and professional software support should matter as well.
• Do these other algorithms scale with the hardware you throw at them? How easy is it to run a read mapping on 64 compute nodes, with 2 CPUs, 8 cores per CPU per node? What about if you double the amount of hardware? Will you go twice as fast? With the GQ- Engine  you will. Want to run on 1024 nodes? That’s possible.
• Are you asking about speed for a single run, or the throughput for a bunch of runs? Last weekend I ran 2000 NGS read databases though our read mapping workflow (low coverage genome sequencing, about 80M reads per database). I started them on Friday afternoon, went for drinks with my friends that evening, had a nice family dinner on Saturday afternoon, and watched a movie with my kid afterwards. The runs were finished before I woke up on Sunday. No hiccups, no failed runs, no logs to monitor, and – best of all – no “one million-file” directories to organize. There were a lot of other customers on the system that weekend, doing their NGS analysis as well.

If we ever meet for a demo, please ask me this question. I love to talk about it.

Henk Heus, Ph.D.
VP Product Management & Services
GenomeQuest Inc.

At GenomeQuest we use an extended version of the GASSST read mapping algorithm (among others). Read about it here in Bioinformatics here: http://bioinformatics.oxfordjournals.org/content/26/20/2534.abstract

Dave Dooling at PolITiGenomics finds two good reasons for considering cloud options: when organizations have peak demands for compute power and when limitations on space/power/cooling preclude building a system in-house. These are two good reasons, but hardly enough to justify all the cloud computing hype.

So, what’s the argument for cloud computing?

Unlike computing which gets cheaper every year, people cost more every year. So, it makes sense to evaluate the annual software development and maintenance costs, the cost of managing the reference databases; integrating and maintaining new applications, the productivity of the end-users and how to change the ratio of end-user-to-support-programmer from 2-to-1 to 10-to-1 or 20-to-1. Cloud computing defined as “Infrastructure” (computers, networks, and storage) doesn’t alleviate these costs.

Of course we have our variant calling workflow, just as we integrate with other variant calling workflows. All of these produce GenomeQuest-native browsable, mineable, and queryable databases. And because of the GQ Engine, we can easily combine sets of 10s or 100s or even 1,000s of these variant databases into a single queryable entity with “web-speed query performance.”

Nevertheless, while our customers get the benefit of the combined data, they often ask for more. So today I jumped in to the APIs of GenomeQuest and tried to address the simple problem of building a table of SNPs that span a series of experiments. Each SNP should have the specific allele called for each experiment in which it was found. A simple little table designed to be the input into any of a number of linkage disequalibrium mapping packages. I made a GQ Plug-in: 5 lines of code to make it accessible in the user interface, and another 100 lines of code (I’m wordy) on the back-end to build the table and present it. And so, the multi-experiment haplotype table is born. I might even convince the development team to include it in our next live push.

If you want to hear more or check out the code, drop me a line.

Richard J. Resnick
VP Software and Services

So what took so long? Until now, it wasn’t necessary. We provided clear business value to pharma for a well-defined use case. An advisory board might have even been a distraction.

So what’s changed? As we build out the sequence data management (SDM) platform, we want to see beyond this year’s application of next generation sequencing (NGS), and make sure we understand where the industry is going.

Dr. Mark Boguski

Mark is a perfect advisor for this initiative. His practical experience at NCBI, Rosetta, and Novartis, and his current vantage point at Harvard Medical School and Beth Israel, places him squarely with a view to the future uses of sequence data in a clinical setting, and with firm grounding in the practical applications of sequence data for the past 20 years.

It’s an honor to have Mark join us as a scientific advisor. We hope to build a diverse advisory team to complement him with skills and experiences that reflect the diversity of talents converging on the digital revolution in biology.