Personal genomics is critical to advancing our ability to treat and preemptively diagnose genetic diseases. However, despite the possibilities of personalizing medicine, it remains tethered, in large part, to the weight of some significant computational-side problems. This includes everything from storage to compute to code, all of which were issues on the table at the National Center for Supercomputing Applications’ (NCSA) Private Sector Program Annual Meeting .
During the event, Dr. Victor Jongeneel, Senior Research Scientist at NCSA and the Institute for Genomic Biology at the University of Illinois detailed some of the bottlenecks and potential solutions that keep expectations for personal genomics grounded.
In the case of personal genomics, the problem is not the scientific understanding of the genome itself, it’s how to reconstruct, compare and make sense of the massive data from sequencers. He claims that the disruptive part of this technology as a whole is rooted in our ability to actually acquire the data. According to Jongeneel, the amount of DNA sequence data generated last year was more than what had been generated over the entire history of sequencing before that.
Personal genomics is anything but a reality right now Jongeneel says. He notes that the range of new services that offer to sequence your genome for a few hundred dollars are far from complete service. These simply take DNA from a saliva kit, probe for a certain number of positions in genomes that are known to be variable and then try to deduce personal characteristics from that information. He claims that this is not personal genomics because in such a case, all you’re examining are known differences between individuals in the population—not your own genome. Besides, to do what is required for a genuine look at one’s personal genomics is far more computationally-intensive and would entail far more than a measly few hundred dollars.
To realize true personal genomics, all differences between individuals need to be analyzed. Jongeneel explained that we are moving toward this more comprehensive genomic sampling via well-funded projects like the 1000 Genomes Initiative, which aims to allow the generation of all necessary data for $1000. He says this soon will be possible but again the computational bottlenecks are the main limitation.
Jongeneel cites three of the main technology vendors that are providing next-generation sequencing and says that while their approaches differ, on average, for a sequenced genome they’re running for 8 days for 200 gigabases worth of information. This translates into well over one terabyte per human genome.
When it’s human genomes sequences are the result of several hundred million (or even a billion) reads—a number that depends on the technology vendor. From there, researchers need to determine where they come from in the genome relative to common reference genomes. This “simple” alignment process whereby the individual genome is compared via alignment with the reference genome is incredibly demanding computationally—as is the next step where one must interpret this alignment to document individual differences and to make sure there is consistency.
Jongeneel says that this alignment step typically takes several days just for the processing of a single sample as it is aligned to the reference genome. To further complicate the process, we all have pieces of DNA that aren’t necessarily found in the DNA of others. While these are small differences he says these can make a very big difference. Analysis of these unique pieces require a complete piecing together of individual reads to allow researchers to see what the larger structure of the genome might look like. And it gets even more demanding.
Rebuilding genomes requires the construction of highly complex graphs, which itself is a strain on computational resources. This is even more demanding when one must disambiguate the graph to make sense of it in terms of an actual genome sequence. After all, there are pieces of sequence rolling off the machines that are on the order of between 75-100 nucleotides long—and you’re trying to reconstitute genomes that are in the millions or billions of nucleotides long. This is the scientific equivalent of fitting a cell-sized piece into a massive tabletop puzzle.
More concretely than the puzzle image, consider this: Jongeneel says that if you wanted to reconstruct an entire genome from this kind of information you’re talking about the construction of a graph would likely have over 3 billon nodes with in excess of 10 billion edges to it. This is, of course, assuming there are no errors in your data which, he apologizes, there probably are. The raw time taken for an algorithm on a medium-sized cluster the assembly properly takes several weeks for each genome.
Jongeneel says that this is the kind of bottleneck that prevents some interesting genomic projects from taking off. For instance, there is currently an effort to sequence the entire range of DNA for several hundred common vertebrates. However, storing that information and spending several weeks for each individual species makes that out of reach—for now, at least. He says that there is hope on the horizon, but it is going to take a rethinking of code and computing.
He says that the problem lies, in large part, in the software itself. His team ran a test on the widely-used genome assembler ABySS, which has broad appeal since it uses MPI and can leverage a much-needed cluster environment. They undertook assembly for a modest-sized genome of a yeast and noted that it was clear, based on wall clock and memory requirements, that this was not a scalable code.
He says this hints at a much deeper problem—many of those developing genomics software aren’t professional developers. Even though they integrate some complex algorithmic ideas, the code they write “isn’t up to the standards of the HPC community.”
He commented on this further, saying that what is needed most is a highly parallel genome assembler. He pointed to some progress in the arena from a group at Iowa State but says that unfortunately, “their software is not in the public domain so it isn’t available, we can’t test it and it’s not in the community.”
A representative from Microsoft in the audience asked Jongeneel about what the solution might be to this problem, inquiring if it was a simple need for more parallel programmers, better tools or languages for developing these, or some other new type of scalable solution. Jongeneel responded that since most of the code being produced is research grade and the technology moves so quickly that it renders “new” code obsolete in very little time. He says that commercial attempts have failed for the same reason—as soon as they’ve produced a viable, scalable solution they’ve been left behind by the swift movement toward new solutions.
Jongeneel said that if you think about personal genomics, if we even wanted to move toward the goal of one million people, we’re going to hit the exabyte range in no time. He feels that in addition these datasets need to be analyzed using workflows with multiple complex steps, thus we require a fundamental rethinking of compute architectures that can enable this kind of research.
That aside, he claims that one side question is what we should do with the massive amount of raw data that is valuable for future research (and sometimes legally sticky to dispose of now anyway). With this raw data in vast volume he says that extraction of ‘relevant’ information is the problem. Jongeneel notes, Data analytics and pattern discovery on large numbers of genomes will be required to produce meaningful results.