Introduction

Collective efforts, such as the Drugs for Neglected Diseases initiative [7], can dramatically speed up the development of novel drugs at a significantly lower cost. Furthermore, repurposing of Food and Drug Administration (FDA)-approved drugs allows to bypass the expensive and time-consuming toxicity assays and clinical trials, greatly reducing the time needed to bring a repurposed drug to the market. In this framework, docking simulations play a central role in the drug development pipeline. However, docking techniques are not readily accessible to researchers outside the structural bioinformatics field, and therefore their potential cannot be fully exploited in community-driven drug discovery initiatives. In the attempt of overcoming the technical difficulties of docking simulations, over the last few years some plug-ins were developed to facilitate them.

Two PyMOL [13] plug-ins exist for docking simulations using AutoDock Vina [14]. The one from the Lill research group is restricted to a Linux environment and requires additional software installation [6], while the one originally developed under Linux by [12] has been adapted for its use in a Windows environment, though apparently tested only on Windows XP. Other examples include AUDocker LE, an AutoDock Vina GUI available under Windows [11] and focused on large scale virtual screening tasks, and DOVIS 2.0, a parallel virtual screening tool for Linux clusters based on AutoDock 4.0 [5]. An AutoDock Vina interface for setting up docking simulations is also available as part of the UCSF Chimera molecular visualization program [10], although it appears more suited to expert than novice users. Recently, another PyMOL plug-in, the NRGsuite, has been described, which allows to perform docking simulations in real time using FlexAID [2]. Of note, the latest PyMOL executables are commercial products and the only officially-supported approach for building and installing PyMOL from the source code is under an open-source environment such as Linux.

Here we present DockingApp, a freely-accessible, platform-independent application for setting up, performing and analyzing the results of docking simulations using AutoDock Vina in a painless and extremely user-friendly way. The application comes with a pre-built library of more than 1400 ready-to-dock, FDA-approved drugs for virtual screening and drug repurposing initiatives. In addition, other, much larger databases of small molecule compounds can be easily plugged into DockingApp, such as the renowned ZINC database [4], available in pdbqt AutoDock format at the URL http://zinc.docking.org/pdbqt/.

Methodology

As briefly stated in the Introduction, DockingApp is born as a user-friendly software application meant to allow a variety of differently-skilled users to perform docking simulations, with high confidence on the results produced and minimal effort for setup and configuration. The former feature is guaranteed by relying upon the state-of-the-art docking program AutoDock Vina, which is the “engine” used by DockingApp to carry out the actual docking simulation; the latter feature is provided by a user-friendly graphical interface that on one hand hides all the complexity behind AutoDock Vina’s usage, and on the other hand allows for a convenient browsing of the results both in tabular form and via a three-dimensional visualization of the receptor and the identified docking poses. All of this was made possible by the development of a platform-independent graphical user interface or “wrapper” (developed in Java), whose purpose is to both acquire the user’s input and process the docking results, and by a Python program that is launched “behind the scenes” and is responsible of interacting with the included AutoDock Vina in the user’s behalf. Further details of the application are described in the following subsections.

Initial configuration

DockingApp requires a minimal configuration effort, related to the selection of the number of CPU cores to be used for AutoDock Vina’s execution and the specification of the installation directory of MGLTools [1, 8], which is a free Python library available for most platforms (Windows, Linux, OSX etc.) and is required for the software to run. The appropriate MGLTools distribution is already included for the respective operating system in DockingApp’s packages. This setup can be done via the “Initial settings” panel (Fig. 1), which is automatically loaded at startup when the application is run for the first time, and can be recalled at a later date as the user needs. The default value for the number of CPU cores is set at half of the detected cores on the system; besides, DockingApp tries to automatically detect the location of MGLTools’ installation directory on the system via a heuristic search, and if found, the corresponding field is populated with the identified directory.

Fig. 1
figure 1

DockingApp’s Initial settings panel

Full size image

Execution of docking and virtual screening jobs

DockingApp provides the user with the possibility of carrying out docking simulations on a given receptor, either against a single ligand (via the “Docking” panel) or a library of small molecules (via the “Virtual Screening” panel). In the former case, the user needs to specify the receptor and the ligand to be docked either as .pdb or .pdbqt files, whereas in the latter, instead of a single ligand, the user needs to select a folder containing the molecules the input receptor will be screened against in .pdbqt format (see Fig. 2). The automatic conversion of the input receptor and ligand from the .pdb to the .pdbqt file format, required by AutoDock Vina to run, is performed by DockingApp by using the prepare_receptor4.py and prepare_ligand4.py MGLTools scripts, respectively.

Fig. 2
figure 2

Input panel for DockingApp’s virtual screening execution

Full size image

Regardless of the type of execution chosen, the user is given the chance to choose a “Grid type” and a “Docking/VS type” (Fig. 2). As a matter of fact, the search-space grid can be either automatically computed by the application to encompass the whole receptor molecule, as in a “blind docking” run, or manually specified by the user via the selection of a set of grid-bounding residues. In the former case DockingApp automatically calculates the grid center as the geometric center of all the atoms of the receptor’s structure. In the latter case the grid center is calculated in a similar manner using the set of atoms of the manually specified residues. Once the grid center is set, the system calculates the monodimensional distances between the center and each atom along the three x, y and z axes. The size of the grid box along the x, y and z axes is then computed by doubling the maximum value of the relative mono-dimensional distances along each dimension, adding to these values 5 Å to ensure that the grid box encloses all the atoms of either the receptor’s structure or of the subset of residues chosen by the user.

Docking/virtual screening (VS) can be either “rigid” or “flexible”: in the latter case, the user needs to choose the flexible residues of the input receptor. Specific panels are provided for the selection of the grid-bounding residues and for the flexible residues, featuring comboboxes where residues can be either selected from the provided drop-down lists or directly typed in the auto-completable text fields, as depicted in Fig. 3. For a default execution, the grid is automatically computed and the docking/VS is rigid, and thus the user needs only to select the input receptor and the input ligand (in the case of one-to-one docking) or the input database (for virtual screening; one is provided by DockingApp as described below), minimizing the complexity of the simulation. In the case of a flexible docking, the prepare_flexreceptor4.py MGLTools script is used by DockingApp, in a transparent fashion with respect to the user, to prepare the additional input file required by AutoDock Vina for flexible docking simulations.

Fig. 3
figure 3

Input panel for DockingApp’s docking execution, where the user has chosen to manually specify the docking grid by selecting the appropriate grid-bounding residues, as shown in the corresponding subpanel. Here, the user can select any number of residues, either by browsing their list from the input receptor or by starting to type their name in the text fields and taking advantage of the autocomplete features provided for convenience. A similar subpanel is displayed when the user opts for a “flexible” docking, allowing the user to select the flexible residues

Full size image

Once all the selections are made and confirmed, DockingApp starts the corresponding execution by launching the included AutoDock Vina, which is responsible of performing the selected docking/virtual screening operations. Specifically, this is done by using a Python script, which interacts and exploits MGLTools to produce the configuration files needed by AutoDock Vina and then launches the actual call to the latter, in a completely transparent fashion with respect to the user. Obviously, virtual screening executions may take a long time to complete based on the processing power of the machine used and the processor cores available, especially when screening against a large set of molecules; it must be noted that DockingApp must be kept open during the process. At the present time, a dataset of 1466 FDA-approved small molecules is provided bundled with the application. Such dataset was downloaded from DrugBank [15] and was originally composed of 1584 small molecule drugs. Since each compound was represented in two dimensions, i.e. its atomic coordinates were given in a bidimensional reference system instead of a three-dimensional one, a procedure to convert the bidimensional coordinates to three-dimensional ones was carried out. For this purpose the MolConverterFootnote 1 utility was used. Afterwards, the resulting PDB files were in turn converted to the .pdbqt format via the aforementioned prepare_ligand4.py MGLTools script. It must be noted that, of the original 1584 molecules, 118 could not be converted due to “unknown atom type” errors encountered during the process (e.g. platinum, arsenic, etc.). The resulting set is provided within the “input/LigandDatabase” folder of the application to be used for virtual screening analyses. As already mentioned, other databases of small molecules in .pdbqt format can be easily plugged into DockingApp by just placing them in a corresponding folder within the input directory.

Visualization of results

Results produced by the docking/virtual screening process are made available by DockingApp via an interface showing several elements.

Firstly, a table is displayed listing the identified poses with their corresponding affinity valuesFootnote 2, RMSD upper and lower bounds, the corresponding ligand and file name, as well as an additional value dubbed SILE (Size-Independent Ligand Efficiency). The latter has been introduced by [9] in order to provide a measure of the docking energy unbiased by the size of the respective molecule, useful to evaluate the potential effectiveness of a compound as a drug and to guide the drug-design optimization process. The SILE is defined as follows:

$$\begin{aligned} SILE = \frac{affinity}{N^{0.3}} \end{aligned}$$

where N denotes the number of heavy atoms in the considered molecule.

Secondly, a panel for filtering the results by different criteria is provided beside the results table, as detailed in Fig. 4. Finally, a three-dimensional view of the input receptor is shown, with the identified docking poses highlighted in different colors, whose display can be turned on or off by the corresponding checkboxes in the table records.

Results can be saved by the user as .dck files (DockingApp’s file format) to be stored and re-opened at a later date at the user’s convenience. A screenshot of the results displayed after a virtual screening execution is shown in Fig. 4.

Fig. 4
figure 4

Screenshot of DockinApp’s output window for a virtual screening execution. Users can turn on or off the differently-colored poses in the three-dimensional visualization by simply checking/unchecking their corresponding checkboxes. The table of the results can be reordered by different sorting parameters by clicking on their corresponding table header. Besides, the “Filters” panel enables the user to dynamically filter those results below a certain affinity threshold, or those with a given affinity difference with respect to the best pose, or simply those that exceed a certain maximum number of records, and/or those results involving specific ligands. Furthermore, three-dimensional visualization is provided via a full-fledged JMol window retaining all JMol’s functionalities, including the input console for specifying further commands in the JMol syntax. The docking grid used in the process, displayed as a red cubic wireframe, can be toggled on and off via its corresponding checkbox. Results can be also saved in DockingApp’s file format and re-opened when needed

Full size image

Technology, requirements and availability

DockingApp is a 64-bit stand-alone software application developed in Java SE 7 and Python, with a Java Swing Graphic User Interface (GUI). It embeds AutoDock Vina and the JMol visualization program [3], and can be run locally on any major 64-bit OS equipped with a suitable Java Virtual Machine (JVM). Packages for Linux, Mac OSX and Windows are provided, each including the required MGLTools distribution (ver. 1.5.6) for the corresponding operating system. DockingApp is available for download at the following URL: http://www.computationalbiology.it/software.html. DockingApp is provided via a GPL license and its source code is available upon request to the authors.

Conclusion

In this work the implementation and features of DockingApp has been described, which is a Java-based AutoDock Vina “wrapper” that can be used to speed up and facilitate docking simulations and the analysis of their results in an intuitive, painless and user-friendly fashion. With DockingApp, even “naive” users, non expert in structural bioinformatics, can perform docking simulations and virtual screening tasks, thus increasing the number of researchers working in the biomedical field who can take advantage of these techniques for the development of new drugs. Finally, the extremely user-friendly character of DockingApp makes it also an excellent tool to be used in educational settings to teach the basics of molecular docking and attract students towards the structural bioinformatics field.