Antibody Docking on the Amazon Cloud

Today an article I wrote for Bio-IT World was published describing Antibody docking experiments that are running on Amazon EC2. Since my final edits didn’t make the deadline I wanted to post the entire article here with some inline links.

It was 18 months ago in this column that Mike Cariaso proclaimed, “Buying CPUs by the hour is back” in reference to our work with Amazon’s Elastic Compute Cloud (EC2). Back then, we were perhaps a bit far ahead of the hype vs. performance curve of cloud computing. A handful of forward-thinking companies were finding ways to scale out web services. Few research groups were putting EC2 instances to work for real number crunching in the life sciences. In the last two years, utility computing has begun to make an impact on real world problems (and budgets) in many industries. For researchers starved for computing power, the flexibility of the pay-as-you-go access model is compelling. The Amazon EC2 process makes the grant process used by national Supercomputing centers look arcane and downright stifling. Innovative and ‘bursty‘ research requires dynamic access to a large pool of CPU and storage. Computational drug design is a great place to begin to clear the air about the reality of this emerging technology.

Accelerating the creation of novel therapeutics is priority one for the research side of the pharmaceutical industry. Much time is spent optimizing the later phases of clinical trials in many pipelines. However, IT and infrastructure decisions made much earlier in the process can have a profound impact on the momentum and direction of the entire endeavor. For protein engineers at Pfizer’s Bioinnovation and Biotherapeutics Center, the challenging task of Antibody docking presents computational roadblocks. All-atom refinement is the major high performance computing challenge in this area.

Respectable models of a protein’s three-dimensional structure can usually be generated on a single workstation in a matter hours. After building multiple models, a refinement step typically produces the most accurate models. Atomic detail is necessary to validate whether newly modeled antibodies will bind their target epitopes and to get a clear picture of the protein-protein interactions and binding interfaces of these immunogenic molecules.

1gla

One of the most successful frameworks for studying protein structures at this scale is Rosetta++, developed by David Baker at the University of Washington. Baker describes Rosetta as “a unified kinematic and energetic framework… (that) allows a wide-range of molecular modeling problems … to be readily investigated.” Refinement of antibody docking involves small local perturbations around the binding site followed by evaluation with Rosetta’s energy function. It’s an iterative process that requires a massive amount of computing based on a small amount of input data. The mix of computational complexity with a pleasantly parallel nature makes the task suitable for both high-end supercomputers and Internet-scale grids.

BBC Two

When Giles Day and the informatics team at Pfizer BBC designed its antibody-modeling pipeline using Rosetta, it soon realized it had a serious momentum killer. Each antibody model took 2¬–3 months using the 200-node cluster. With dozens of new antibodies to model, the project was at a standstill until they could get enough compute capacity to do the appropriate sampling. Furthermore, the pipeline was invoked with unpredictable frequency since it was dependent upon discovery in other departments. What it needed was a scale-out architecture to support “surge capacity” in docking calculations. This surge could happen frequently or not at all, making capacity planning extremely difficult.

Traditionally options were limited to expanding in-house resources by adding more nodes to the cluster or reducing the sampling. 4amd The only true option was to throw more CPUs at the problem — a doubled capacity could potentially halve a two-month calculation – but would necessitate acquisition, deployment, and operational costs. After evaluating those costs, they contracted the BioTeam to provide them with a cloud based solution. The result was a scalable architecture custom fit to their workloads and built entirely on Amazon Web Services (AWS). As was clearly evidenced at this year’s Bio-IT World Expo, the Cloud is mainstream today. Moreover, the AWS team is years ahead of the competition. AWS is unveiling new features and API improvements almost every month. The AWS stack is fast becoming a first choice by BioTeam for cost-effective virtual infrastructure and high-performance computing on-demand.

The architecture employed for docking at Pfizer makes use of the nearly the entire suite of services offered by Amazon. A huge array of Rosetta workers can be spun up on EC2 by a single protein engineer and managed through a web browser. As Chris Dagdigian pointed out in his recent keynote at Bio-IT World: While the cloud is quite hyped, this isn’t rocket science. The Simple Storage Service (S3) stores inputs and outputs, SimpleDB tracks job meta-data, and the Simple Queue Service glues it all together with message passing. What Amazon did right in 2007 was elastic compute and storage. What they do better in 2009 is to provide developers everywhere with a complete stack for building highly efficient and scalable systems without a single visit to a machine room. The workloads at Pfizer that previously took months are now done overnight and the research staff can focus on results without pushing their projects on the back shelf.

Plenary Keynote

bio-itworld09

The Bio-IT World Conference & Expo ‘09 took place last week in Boston. Highlights included my role model and colleague Chris Dagdigian giving the plenary keynote. Slides can be found at blog.bioteam.net. The keynote was extremely well received by the audience and his talking points resonated throughout the conference.


dag-1.png

Continue reading ‘Plenary Keynote’

Thirty Years of (Bio)Molecular Simulation: How Far Have We Come?

This was originally intended to be micro-blogged talk. Probably on friendfeed. But when I walked into the old Chevron building on the Pitt campus to listen to Professor Wilfred van Gunsteren the wireless was spotty, so I saved my notes for a triumphant return to normal blogging. The talk is part of a lecture series presented by the CMMS at the University of Pittsburgh. Since it was probably the intended purpose when I started Bleeding Edge Biotech; this is my notepad of the distinguished lecturer’s slides and talking points.

Continue reading ‘Thirty Years of (Bio)Molecular Simulation: How Far Have We Come?’

CryoEM of Nanomachines

There was a time in structural biology when solving protein structures using NMR was received with considerable skepticism. In addition to the normal experimental uncertainty, the technique generated structures with additional uncertainty due to the vibrational motions of proteins in solution. That’s part of the reason standard NMR entries in the PDB contain ~20 structures while x-ray structures have just one. However modern NMR methods have advanced to the point that few skeptics are left. The two techniques together were essential in the rapid increase of structural information that’s available today.

Continue reading ‘CryoEM of Nanomachines’

Achieving Your Childhood Dreams

RIP Carnegie Mellon Professor Randy Pausch (Oct. 23, 1960 - July 25, 2008)

Impressions from ISMB 3Dsig

This past weekend I attended my first ISMB conference in Toronto, ON. I didn’t have time to attend the main conference but I did enjoy the 3Dsig satellite meeting in the days preceding the main event. During the talks, I used twitter to jot down some brief notes. Here’s the rundown of my favorite 3Dsig keynotes:

Continue reading ‘Impressions from ISMB 3Dsig’

Hybrid Programming for Shared-Memory and Clustered SMP Systems

There’s an upcoming workshop at the PSC September 8 - 11, 2008

This workshop will present programming models and techniques for writing efficient parallel code on contemporary and future supercomputers with extensive shared memory, or hierarchical architectures with smaller shared-memory components. Two important examples of systems to which these techniques apply are the SGI Altix and networked clusters of multicore processors. Expert instructors from PSC and SGI will review MPI, OpenMP, and hardware architecture prior to launching into detailed treatments of programming for hybrid parallelism, performance analysis, and optimization. This is a “bring your own code” workshop. Participants are encouraged to bring an application to focus on during the hands-on sessions to maximize the workshop’s effectiveness. Examples will be provided for participants who cannot bring a research code. Experienced PSC computational scientists will provide support regarding the topics covered, including hybrid algorithms and implementation strategies and performance engineering.

More details

Solve Puzzles for Science - FoldIt: An online protein folding game

David Baker is one of my favorite scientists. His group performs the best at CASP. He started the Rosetta protein folding and design software and Rosetta@HOME a distributed computing network to run it. And now he’s behind one of the coolest projects I’ve ever seen. Fold.it is an amazing community-based game where players can compete by folding proteins in a graphical point and click manner. Fold.it has a beautiful UI and molecular graphics not unlike the ones you’ve come to expect from VMD, PyMOL, and UCSF Chimera. Most importantly, this highly addictive puzzle game has real scientific value. Each time you solve a folding puzzle, the software sends your results back to FoldIt. With that data they hope to gain insight into the powerful human capacity to recognize patterns and apply that to new protein structure prediction methods. Players can create and join groups to compete against other players for high-scores.

After playing FoldIt for about an hour the game is actually very fun and addicting! Any game with actions like “Shake Sidechains” and “Wiggle Backbone” is guaranteed to make any bioche/biophysicist smile. While it may compete with GTA4, this game is a huge step in educating students in protein structure. It’s truly brilliant. Thanks to Andrew Perry for pointing this out.

FoldIt - Crowdsourcing to solve the protein folding problem

Using Ruby for Bioinformatics Applications

bioruby

When I started working in a bioinformatics research lab I quickly discovered the wonderful dynamic language that is Perl. I’ve spent a couple of years with Mastering Perl for Bioinformatics somewhere on or around my desk. Perl itself was designed with text-processing and reporting in mind so naturally it’s become widely used when handling biological data.

So everything bioinformatics should be coded in Perl, right? A couple of years ago I might have agreed, but now I feel differently. My first “Perl, I’m leaving you.” moment came when I discovered the way that Rails does web programming. Ruby is the magic in Rails, but I soon discovered Ruby goes much beyond web frameworks. To quote Ezra:

“I came for the Rails, but I stayed for the Ruby”

I wanted to compile some links to show how an active community is positioning Ruby to be a powerful language for bioinformatics programming:

BioRuby - open source bioinformatics library

BioRuby on Github

Web Frameworks

Ruby on Rails - the famous MVC framework that made ruby popular

Merb - fast, lightweight MVC framework

Camping - 5k microframework

Sinatra - web development DSL

Ramaze - simple, light, and modular web application framework

Rack - Webserver interface

Distributed/Parallel Computing

DRb- Distributed Ruby

SkyNet- Map Reduce in Ruby

Rinda - Linda parallel programming model in Ruby

rxgrid - Xgrid batch language

MPI Ruby - MPI bindings for Ruby

amazon-ec2 - Amazon EC2 API

Testing/Spec

RSpec - BDD framework

Test::Unit - Unit testing in the Ruby standard library

Integration with other programming languages

JRuby - JVM ruby implementation

SWIG and Ruby - automatically generate C interfaces

Ruby C extensions

Math/Statistics

Ruby-GSL - wrapper for the GNU Scientific Library

RSRuby- R statistics package in Ruby

SciRuby

Ruby NArray - similar to NumPy

Visualization/Graphics

Ruby Gnuplot - Gnuplot bindings

Ruby-Processing - The Processing language in Ruby

ruby-opengl - OpenGL bindings

Gruff - Graph API

Ruby-SVG - SVG Graphics

Ruby Gnuplot

Machine Learning

AI Related Ruby Extensions

Support Vector Machines in Ruby

Fast Artificial Neural Network library

Blogs about bioinformatics and Ruby

Saaien Tist - Jan Aerts, on bioinformatics and personal productivity

Bioinformatics Zen - Micheal Barton

Be sure to visit the Ruby for Bioinformatics room on FriendFeed for even more Ruby goodness.

A Pipeline is a Rakefile

Update: Mike over at Bioinformatics Zen has written a more thorough post about organised bioinformatics experiments with examples using Rake and DataMapper. Definitely check that out.


image credit: railsenvy.com

Make and it’s other revisionings tackle the challenging problem of dependency injection which is somewhat analogous to the Strategy pattern. Make is a tried and true Unix utility that does the heavy lifting each time you type “./configure; make && make install” inside a large chunk of open source goodness. Make became such a popular tool because it drastically reduced compilation times for large programs. In compiled languages such as C, each time a source file is changed it needs to be recomplied. Rather than rebuild the entire project everytime the source code is changed, an expert (a C programmer in this case) can specify dependencies so that make will build only the files that change and their dependencies. In that sense, it’s easy to take for granted how powerful a Makefile actually is. Make is an expert system that’s ubiquitous in the Unix world.

A makefile has the basic structure:


	target: dependencies

		command 1

		command 2

	          .

	          .

	          .

		command n

Which brings us to the actual point of this post; how to use Makefiles in bioinformatics. There’s a discussion on nodalpoint from 2007 that calls for the use of `make` more often when programming pipelines. This made perfect sense. In bioinformatics we do pipelines all the time.

Sequence analysis

Blast search -> Multiple sequence alignment -> Phylogenetic analysis

Homology Modeling

Find Template -> Align target-template -> Build model

Molecular Dynamics

Solvate -> Equilibrate -> Simulate -> Analyze

Those aren’t the most detailed examples but hopefully you get the idea. Each step is dependent on the previous step. If one single step takes a lot of computation time, it would be nice to skip that step if it’s already been done. There’s also a benefit to encoding expert knowledge. For example, how do you convert a .fasta sequence file to a .pir sequence file? By specifying a rule, a build system will know what to do everytime is sees a ‘*.fasta’ file in your project.


	%.pir: %.fasta

	./fasta2pir $< $@

But Makefile syntax can be tricky (is that a tab or a space?), and it’s not a full blown programming language by itself. Which is why I fell in love Rake.

Anyone who has tried out Ruby on Rails probably typed something like “rake db:migrate” without realizing what rake is all about. Rake is Ruby Make. Rake was designed to be just like make, but with all the power and flexibility of the Ruby programming language. A Rakefile is simply a set of tasks, which can have one or more dependencies. Unlike make, rake is an internal DSL since it morphs Ruby into a build language without losing it’s utility as a general purpose language.

A simple Rakefile in your bioinformatics project could do something like this:


	task :queryDatabase do

	  puts "Fetched Records"

	end

	task :formatData => :queryDatabase do

	  puts "Converted to XXX format"

	end

	task :createPlot => :formatData do

	  puts "Generated a Figure"

	end	

This says “before I formatData I must queryDatabase”, and “before I createPlot I must formatData”. So as you might expect, when you type:


	$ rake queryDatabase

	Fetched Records

	$ rake formatData

	Fetched Records

	Converted to XXX format

	$ rake createPlot

	Fetched Records

	Converted to XXX format

	Generated a Figure

And our Fasta rule in Rake would look like:


	rule '.pir' => ['.fasta'] do |t|

	  sh "./fasta2pir #{t.source} #{t.name}"

	end 

Pretty cool? Obviously these tasks don’t actually do much other than show how rake resolves dependencies for you, which can be a pretty powerful thing for hacking together a pipeline.

Rake resources: