BOINC Project Setup for Virtual Drug Screening

This page summarises and introduces to the employment of BOINC to orchestrate tasks for the docking of small chemical compounds to a protein. This is commonly a flexible ligand fitted to a solid structure - or a fit to a set of structures that capture the protein in various moments. The world has seen several projects on docking with BOINC before, e.g. aforemost the World Community Grid's FightAids@Home and others of the WCG realm, but there is also Docking@Home and the Rosetta team could prepare a docking experiment at any time.

Our ambition is to bring all components directly into a regular Debian package or present it as a dependency. The authors of this page have their own in-house BOINC-based AutoDock project going, with all components available on Debian, but to round it all up, the development is still ongoing - and particularly so is this documentation. For joining in, please contact us.

1. Conceptional Overview

The project is centered around Debian as the sole source of all software tools required for the project and for an automated retrieval of data. The BOINC client is shipping with Debian-proper since a long time. The BOINC Server we decided to leave in the experimental section of Debian, so we can update this publicly exposed software at any time.

Other than Debian's packages for SETI and Milkyway client applications, there is no dedicated package for this docking project. The binary, i.e. AutoDock Vina in this first developmental stage, is wrapped and both the wrapper and its piggyback vina application are both sent once to every participating client. Ideas for optimisations should be sent to the (very responsive) upstream authors at Scripps.

BOINC_Server_AutoDock_Overview.png

In the following, we describe the yellow arrow of above figure, i.e. how to get from the boinc-server-autodock Debian package with the help of what is shipping with boinc-server-maker to a web site that invites users to contribute and to a repository of ligand evaluations that can be interpreted by Raccoon. All scripts described or referenced below (if not referenced directly) are available from the git repository.

2. Preparation of BOINC side

The AutoDock BOINC project first of all is a regular BOINC project. All tools one knows about how to set up BOINC projects are working completely the same. We prepared a script to set up the AutoDock project at a predefined location with no human intervention. As nice as it is, please take the extra time to mentally follow the BOINC/ServerGuide. This transports a bit - not too much - of an extra understanding on how BOINC works internally, which we consider to help you all in helping us to improve the workflow. The current implementation is working solely with AutoDock Vina. Support for the classical AutoDock 4.x was once described on BOINC/ServerGuide/AutoDockApp and has yet to be updated and incorporated into our scripts.

The executable scripts all reside in /usr/share/boinc-server-autodock/bin. All BOINC-specific preparation is completed with the script "install.sh" in that directory. Caveat: This first cleans the database, do not use it inadvertedly. Then, it invokes separate scripts to perform steps 2.2 and 2.3 as described below.

2.1. Project-specific configuration

The script install.sh expects a set of environment variables to be defined. By default all the values are being retrieved from the script autodockvina_set_config.sh.

2.2. Install BOINC web server

The tool autodockvina_install_project.sh performs

At this point, users can subscribe to the project and wait for work units.

2.3. Prepare AutoDock Vina binaries and inform BOINC about them

To script autodockvina_install_apps.sh continues with

The project is functional now, except for the missing workunits.

2.4. Comments

In a perfect world there would be no need wrappers. Instead, we would patch the AutoDock application to learn how to use the BOINC file descriptors. Also, we should indicate the progress in a file for BOINC to display to the user. For single ligands, though, AutoDock Vina is so quick, that this seems not to be required to help the user experience, much. For multiple ligands to be executed within the same work unit, the granularity of the progress indication is with the percentage of ligands evaluated.

3. Preparation of Docking side

It may be convenient to keep AutoDock Vina configuration files, receptor and ligands models on the same machine that runs BOINC server to avoid large data transmission over network. PDBQT files for the receptors and ligands of interest may be prepared with use of utilites from ?AutoDockTools. A number of prepared ligand sets can be downloaded from http://zinc.docking.org/pdbqt/. To automate the retrieval, install the ?getData Debian package. The one-time configuration of the receptor for the docking is performed as for every docking project with AutoDock and is supported by the MGLTools. Debian supports the CADD tool "Raccoon", which also features an interface to perform this preparation.

3.1. Make a database of receptor models for screening

For the bash commands below we will suppose that receptor files, in PDBQT format, are kept in /home/boincadm/my_autodock_vina_library/receptors.

3.2. Make a database of ligand models for screening

For the bash commands below we will suppose that ligand files, also in PDBQT format, are kept in /home/boincadm/my_autodock_vina_library/ligands.

3.3. Set configuration parameters for docking

For the bash commands below we will suppose that configuration files are kept in /home/boincadm/my_autodock_vina_library/configs.

4. Management of running project

Results are collected without human intervention. The challenge is to create the right set of work units.

4.1. Assimilator program for collecting docking results

We suggest to use the sample assimilator as provided by BOINC itself and already installed by above described install.sh script. It collects the output files as returned from the boinc-clients into a folder named sample_results under the main project directory. With literally millions of ligands tested against several structures, this takes considerable disk space. As an optimisation, a more sophisticated assimilator could possibly extract only the predicted energy values and coordinate files. Alternatively, one just buys another hard disk - we decided not to care and to be happy about the possibility to characterise the involvement of side chains in the binding and otherwise interpret the molecular data.

4.2. BASH script to generate workunits

Every scientific application has its own - sometimes multiple - ways it may be used. For AutoDock Vina, the script autodockvina_generatework.sh automates the generation of workunits. It expects ligands and receptor libraries to have been prepared and to reside in a location as initially configured (@Natasha - please correct or render it otherwise more practical).

The workflow template raccoon-autodockvina_wu_template.xml specifies the receptor as invariant between compute jobs to avoid redundant downloads. The short compute time of single ligands with vina invites to have multiple ligands submitted together as a workflow. For the moment this is not implemented - it works as it is and the handling of results on the server side seems easier. Also, when changing the technology, e.g. back to the classical AutoDock 4.x, compute time is likely to increase again.

5. Result Collection

Figure_BOINC_Wiki_Dataflow.png

The docking proceeds quickly. And patience is often not a prime attribute of contributors. They want to know how well their computers have performed. Thus, there is a script to identify the best performing ligands on a routine basis. For the interpretation of the findings, one wants pet datasets analysed on more than a single structure. This could be representative states in a molecular dynamics simulation or the structures known or predicted for orthologue receptors, i.e. the functional equivalents in other species. One may also be in doubt e.g. of protonation states and some structures in PDB have alternatives indicated in their coordinates - this adds to the already impressive combinatorical might of the challenge.

After first runs, one will seek for patterns in ligands that are associated with success. Ligands featuring those patterns, possibly despite a mediocre performance in an initial screen on a first structure, will be granted a chance to perform on a larger variety of structures in subsequent runs.

5.1. Results filtering

Having the simplest assimilator implementation, it requires additional effort to process the work results. The best compounds names may be extracted from the output files with use of a tool autodockvina_get_top_energies.sh provided by boinc-server-autodock package. This script, executed in the directory with output files or with appropriate input parameters, should output the ligands names with binding affinity values. This data may be the first of interest for the project owner, and the script may easily be extended to extract more detailed information about docking results from the output files and the database. From the social point of view, it can be interesting to get the list of top ligands together with the names of users whose computers found them, and to display them at the project website.