Webina: an open-source library and web app that runs AutoDock Vina entirely in the web browser

Abstract Motivation Molecular docking is a computational technique for predicting how a small molecule might bind a macromolecular target. Among docking programs, AutoDock Vina is particularly popular. Like many docking programs, Vina requires users to download/install an executable file and to run that file from a command-line interface. Choosing proper configuration parameters and analyzing Vina output is also sometimes challenging. These issues are particularly problematic for students and novice researchers. Results We created Webina, a new version of Vina, to address these challenges. Webina runs Vina entirely in a web browser, so users need only visit a Webina-enabled webpage. The docking calculations take place on the user’s own computer rather than a remote server. Availability and implementation A working version of the open-source Webina app can be accessed free of charge from http://durrantlab.com/webina. Supplementary information Supplementary data are available at Bioinformatics online.


Typescript
To facilitate use, we have incorporated the Webina library into a convenient web app. The app is written in the open-source Microsoft TypeScript programming language. TypeScript is similar to JavaScript, but it includes additional features (e.g., optional variable typing, standard classes and interfaces, etc.) that are particularly useful when creating and maintaining complex codebases. TypeScript compiles to JavaScript and so can run in any modern web browser.

User Interface
The Webina web app leverages Vue.js 2.6.10 (https://vuejs.org/), an opensource JavaScript framework for building single-page web applications with consistent user interfaces. Vue.js allows web programmers to create their own reusable HTML-like components (e.g., text fields, buttons, etc.). The properties and values of each component may depend on userinitiated actions (e.g., a "Submit" button may only be enabled once the user has entered text into an associated form). With each user action, Vue.js automatically updates all dependent components throughout the entire app. The Vue.js framework thus greatly simplifies the process of creating complex web apps with many interconnected features.
We also use the open-source BootstrapVue library 2.0.2 (https://bootstrapvue.js.org/) to ensure that all user-interface components have a consistent appearance. BootstrapVue provides a number of broadly useful Vue.js components (e.g., buttons, check boxes, pop-up message boxes, etc.). These components are styled according to the Bootstrap4 framework (https://getbootstrap.com/), which provides professionally designed templates that dictate components' color, size, and typography.
We also created a custom molecular-visualization Vue.js component that leverages the 3Dmol.js JavaScript library (Rego and Koes, 2015). This component allows the Webina web app to display macromolecular and small-molecule structures in the browser, as required for setting up Webina runs and analyzing Webina output. 3Dmol.js uses native web technologies to display these structures without requiring users to install any program or browser plugin.

Build Process
We use Webpack, an open-source module bundler, to organize and assemble custom and third-party libraries and files (https://webpack.js.org/). Webpack automatically builds the Webina web app by copying required files to their appropriate locations, combining files where possible, removing unnecessary/unused code, etc. Applying Google's Closure Compiler is a critical component of this build process (https://developers.google.com/closure/compiler). The Closure Compiler automatically analyzes and rewrites our TypeScript/JavaScript code to reduce file sizes and speed execution.

PDBQTConvert Web App
We created the PDBQTConvert web app to help novice users prepare their receptor/ligand files for Webina use. Like Vina, the Webina library accepts receptor/ligand input files only in the PDBQT format, a PDB-like format that additionally includes atom types and partial atomic charges. As described in the "Webina and Vina Benchmarks" section below, a number of command-line and other programs are available for converting receptor/ligand input files from popular formats (e.g., PDB, SDF, etc.) to PDBQT. But PDBQTConvert provides an easier way to prepare these files using a Bootstrap4-powered graphical user interface (GUI) in the browser. We distribute the PDBQTConvert app alongside Webina, but as an entirely separate program. Unlike the Webina library/app codebase, which is Apache-2.0 licensed, the PDBQTConvert app is GPLv2 licensed.
PDBQTConvert uses the OpenBabel JS library (Jiang and Jin, 2017) to convert receptor and ligand input files from many common formats (i.e., CAN, ENT, MCIF, MDL, MMCIF, MOL, MOL2, PDB, PQR, SD, SDF, SMI, SMILES, and XYZ) to the Webina-compatible PDBQT format. The app includes several user options. The first instructs PDBQTConvert to include branches and torsion trees, as required to indicate which ligand bonds should be considered rotatable during Webina/Vina docking. A second option instructs PDBQTConvert to add hydrogen atoms per a user-specified pH. Webina/Vina docking requires that receptor/ligand PDBQT files include polar hydrogen atoms. But PDB receptor structures derived via X-ray crystallography often lack the resolution required to place hydrogen atoms, and many popular ligand formats (e.g., SMILES strings) do not enumerate explicit hydrogen atoms. A third option instructs PDBQTConvert to generate 3D coordinates for the input molecule. Many popular ligand formats (e.g., SMILES strings, flat SDF files, etc.) do not include 3D atomic coordinates, but Webina/Vina docking requires fully 3D models.

Input Parameters Tab
To accommodate users who are not web developers, we have incorporated the Webina library into a Webina web app that includes additional tools for setting up Webina runs and visualizing docking results. On first visiting the Webina web app, the user encounters the "Input Parameters" tab. This tab includes several subsections that are useful for setting up a Webina run ( Figure S1).
Input PDBQT Files. The "Input (PDBQT) Files" subsection allows the user to select their receptor and ligand files ( Figure S1A). The user can also optionally specify a known-pose PDB or PDBQT ligand file. This file includes the ligand in its experimentally determined, correct bound pose (e.g., per X-ray crystallography or NMR). The known-pose file plays no role in the docking calculation; rather, it serves as a positive-control reference for evaluating Webina-predicted ligand poses. In our experience, it is often helpful to first benchmark Webina (or Vina) against a known ligand before using the program to evaluate compounds with unknown poses and binding affinities.
The "Input (PDBQT) Files" subsection also includes several options to simplify the process of preparing/testing protein/ligand input files. (1) If users wish only to test Webina without having to provide their own files, they can click the "Use Example Files" button to automatically load example receptor, ligand, and known-pose files. (2) If users specify receptor/ligand input files that are not in the required PDBQT format, the Webina web app will optionally attempt to convert them to PDBQT using the PDBQTConvert app. Interactions between the Webina and PDBQTConvert apps occur at "arm's length" via an iframe. (3) If users' receptor files include non-protein residues that might interfere with docking (e.g., a co-crystallized ligand), they can remove all nonprotein atoms. (4) If users do not have a ligand file, they can use a web-based 2D molecular editor (Jiang et al., 2016) to draw their ligand by hand. PDBQTConvert then converts that 2D ligand representation to a 3D PDBQT file for docking.
Docking Box. The "Docking Box" subsection allows users to specify the region of the receptor where Webina should attempt to pose the ligand ( Figure S1B). This box-shaped volume is typically centered on a known pocket or cavity where a small-molecule ligand might reasonably bind.
To simplify the process of selecting a docking box, the Webina web app automatically displays 3D models of the user-specified receptor and ligand using the 3Dmol.js JavaScript library (Rego and Koes, 2015). By default, the receptor and ligand are displayed using cartoon and sticks representations, respectively. The user can toggle a surface representation as required to identify candidate receptor pockets. A transparent yellow box is superimposed on the structures to indicate the docking-box region.
When the user clicks the atoms of the receptor model, the Webina web app recenters the docking box on the selected atom. Users can also adjust the location and dimensions of the box using text fields below the molecular visualization.
Other Critical Parameters. The "Other Critical Parameters" subsection allows the user to specify the number of CPUs and the exhaustiveness setting ( Figure S1C). We chose to set these two parameters apart because they are particularly important in a browser-based setting. Users expect command-line tools to consume substantial computer resources, but they do not expect web apps to do so. By default, Vina uses all available CPUs and an exhaustiveness setting of eight. Webina has the same ability to consume CPUs and memory, but many users will wish to adjust these parameters to avoid impacting the performance of other programs and browser tabs.
Advanced Parameters. The "Advanced Parameters" subsection allows users to specify many additional parameters that are also available via command-line Vina ( Figure S1D). In our experience, it is rarely necessary to adjust these parameters, so they are hidden by default.
Run Vina from Command Line. The "Run Vina from Command Line" subsection aims to help Vina users who wish to use the Webina web app to setup their docking boxes and user parameters ( Figure S1E). A text field provides a mock example of how to use command-line Vina with the specified parameters. Users can copy this example, modify it as needed, and paste it into their command-line terminals to run the desired calculation with the standard Vina executable. This subsection also includes links that allow the user to download the receptor/ligand PDBQT files for commandline use.
Starting the Webina Calculation. Once users click the "Start Webina" button, the Webina app will switch to the "Running Webina" tab while Webina executes. During this process, the user-specified receptor/ligand files and parameters are never transmitted to any third-party server. The calculations run entirely in the user's browser itself. The Webina browser tab may become unresponsive during execution as a result. Once the calculation is complete, the Webina web app will switch to the "Output" tab (described below) where users can visualize the docking results.

Existing Vina Output Tab
Beyond serving as a platform for running the Webina library, our Webina web app provides a useful interface for visualizing docking calculations. The "Existing Vina Output" tab allows users to load and visualize the results of previous Webina and Vina runs, without having to rerun the calculations. Users must specify the existing receptor and Webina/Vina output file they wish to visualize. They can also optionally specify a known-pose ligand file for reference. Users who wish to test the web app without providing their own files can click the "Use Example Files" button. Otherwise the "Load Files" button will open and visualize the specified files.

Output Tab
The "Output" tab allows users to visualize their Webina docking results ( Figure S2). The same tab also displays the output of any previous Webina/Vina calculations that the user specifies via the "Existing Vina Output" tab.
Visualization. The "Visualization" subsection uses 3Dmol.js to display the receptor and docked molecule in cartoon/surface and sticks representation, respectively ( Figure S2A). If the user has specified a known-pose ligand file, that pose is also displayed in yellow sticks. Like Vina, Webina predicts several poses per input ligand. A table below the visualization viewport lists each pose together with associated information such as the docking score. Clicking on a table row updates the 3D view with the specified pose so users can easily examine all predicted poses.
Output Files. The "Output Files" subsection shows the text contents of the Webina output files ( Figure S2B). An associated "Download" button allows users to easily save those files.
Run Vina from Command Line. Similar to the "Input Parameters" tab, the "Output" tab also includes a "Run Vina from Command Line" subsection ( Figure S2C). This subsection makes it easy for users to reproduce Webina's results using stand-alone Vina. It also reminds users what parameters they selected to generate the displayed Webina output.

Start Over Tab
The "Start Over" tab displays a simple button that allows the user to restart the Webina app. A warning message reminds the user that they will lose the results of the current Webina run unless they have saved their output files.

Preparing Protein-Receptor Files
To compare Webina and Vina, we created a benchmark set of five protein/ligand complexes. To prepare the protein receptors for docking, we first removed all water molecules and ions. We then submitted the protein structures to the PDB2PQR server (Dolinsky et al., 2004), a free resource that adds hydrogen atoms per a user-defined pH while simultaneously optimizing the hydrogen-bond network. We used the default PDB2PQR settings, which assign protonation states at pH 7.
We next used Open Babel (O'Boyle et al., 2011) to convert the output receptor PQR files back to PDB. Vina requires input receptor files to be in the PDBQT format. We used MGLTools 1.5.6 (http://mgltools.scripps.edu/), a desktop program created by the same group that created Vina, to convert the PDB files to PDBQT. We note that Open Babel can also convert files to the PDBQT format, but it does not always assign the same partial atomic charges and ligand rotatable bonds that MGLTools does.
One of the benchmark protein receptors, COX-2, contains heme groups. We similarly used MGLTools 1.5.6 to convert PDB files containing these heme groups to the PDBQT format. We appended these PDBQTformatted files to the COX-2 PDBQT file prior to docking.

Preparing Ligand Files
We used the DrugBank database (Wishart et al., 2006) to obtain the SMILES strings of each input ligand. We then used the open-source program Gypsum-DL (Ropp et al., 2019) to generate protonated ligand models from these SMILES. For each input ligand, Gypsum-DL can generate multiple output PDB files that collectively account for alternate ionization, tautomeric, chiral, cis/trans isomeric, and ring-conformational states. To simplify our analysis, we instructed Gypsum-DL to generate only one molecular variant per input molecule, protonated as appropriate for pH 7. We again converted the Gypsum-DL output PDB files to the PDBQT format using MGLTools 1.5.6.

Webina and Vina Docking
We docked each ligand into its respective receptor using both Webina and Vina 1.1.2 (macOS 64-bit version). In each case, the docking box was centered on the geometric center of the corresponding crystallographic ligand, calculated using the scoria Python library (Ropp et al., 2017). All docking boxes were 20 Å x 20 Å x 20 Å, cubed. Each docking run used four CPUs, an exhaustiveness setting of eight, and a consistent random seed of 123456789. The Webina git repository includes the receptor and ligand PDBQT files, for reproducibility's sake. We measured the rootmean-square deviation (RMSD) between each top-scoring docked pose and the corresponding crystallographic ligand using obrms, a program included in the Open Babel package (O'Boyle et al., 2011).
We used Webina to see whether we could predict LARP1 TOPmotif specificity in silico. We docked both the m 7 GpppC and m 7 GpppG dinucleotides into the 5V87:B DM15 structure, which was co-crystallized with bound m 7 GpppC (Lahr et al., 2017). The m 7 GpppC and m 7 GpppG ligands were prepared using Gypsum-DL as above, except the phosphatebound hydrogen atoms were manually removed. The ligands were docked into a docking box with dimensions 16 Å x 17 Å x 17 Å, positioned so as to encompass both the m 7 G-and +1C-binding pockets. To accommodate the flexibility of the triphosphate moiety, we ran Webina docking using an exhaustiveness setting of 20. Where two poses had the same predicted docking score, we favored the pose that placed the m 7 G cap in the capbinding pocket. See the Webina git repository for the input PDBQT files.
In harmony with previous experimental studies (Lahr et al., 2017(Lahr et al., , 2015, Webina scored the top m 7 GpppC pose slightly higher than the top m 7 GpppG pose (-6.2 and -5.9 kcal/mol, respectively). Notably, the best m 7 GpppC pose captures many of the same interactions seen crystallographically ( Figure S3A) (Lahr et al., 2017). The m 7 G cap forms hydrogen bonds with E886, as well as π-π and cation-π interactions with Y922 and Y883. Similarly, the +1C forms hydrogen bonds with R847 and π-π stacking interactions with Y883 and F844. In contrast, the best m 7 GpppG docked pose did not orient the +1G nucleotide such that its Watson-Crick face could interact with the +1C-pocket protein residues ( Figure S3B).
We do not wish to overstate the utility of docking in general or Webina in particular. Docking certainly has its inaccuracies. For example, when we similarly docked the m 7 GpppC and m 7 GpppG dinucleotides into a LARP1 DM15 mutant engineered to specifically bind +1G transcripts (6PW3:C (Cassidy et al., 2019)), the poses were not nearly as good (data not shown). But, typical docking inaccuracies aside, Webina is still a powerful, user friendly tool for generating biologically relevant hypotheses.

PARP-1 Ligand-Pose Prediction
As a second demonstration of utility, we used Webina to study Poly [ADP-ribose] polymerase 1 (PARP-1), a multifunctional nuclear protein involved in the base and nucleotide excision DNA repair pathways (BER and NER) (Bai, 2015). PARP-1 is overexpressed in various carcinomas and is associated with more aggressive cancer and lower survival rates (Malyuchenko et al., 2015;Rojo et al., 2011). BRCA-deficient carcinomas are especially susceptible to PARP-1 inhibition because they depend solely on BER for survival (Wang et al., 2017).
As expected, the best Webina-predicted binding affinity of each ligand was obtained when each was docked into its corresponding crystallographic conformation: the benzonaphthyridinone derivative, -14.7 kcal/mol; niraparib, -10.1 kcal/mol; and rucaparib, -10.8 kcal/mol. The heavy-atom RMSDs between the crystallographic and top-scoring docked poses were: the benzonaphthyridinone derivative, 2.35 Å; niraparib, 1.15 Å; and rucaparib, 0.77 Å. Having verified that Webina is effective in this context, we next used it to predict the binding pose of pamiparib, a PARP-1/2 inhibitor currently in phase II clinical trials (Friedlander et al., 2019). We docked pamiparib into the same three PARP-1 conformations, using the same Webina parameters. The PARP-1 structure associated with the top-scoring pamiparib pose (-11.3 kcal/mol) was 4HHY:A ( Figure S3C) (Ye et al., 2013). In this docked pose, pamiparib shares much in common with the crystallographic poses of the three positive-control ligands. All four overlay a benzamide substructure at the same location ( Figure S3C), enabling hydrogen bonds with S904 and G863 and a π-π stacking interaction with Y907. To the best of our knowledge, there is no publicly available PARP-1/pamiparib crystal structure. This work thus demonstrates how Webina can be used to prospectively predict ligand poses, a critical component of many CADD workflows.

Standard Vina Executable
Webina has several advantages over the standard Vina executable. Though code compiled to Wasm tends to run somewhat slower than natively compiled code, it runs entirely in the browser. And given that modern browsers already run on all major operating systems, Wasm-compiled programs are cross-platform by default. The Webina web app also provides a helpful GUI that command-line Vina lacks, making computer docking much easier for novices and students.

Third-Party Graphical User Interfaces
Several groups have created GUI-based desktop applications for setting up, performing, and analyzing Vina results. Many of these interact with command-line Vina "under the hood." For example, PyRx (Dallakyan and Olson, 2015), now a commercial program, provides a helpful wizardlike interface for Vina docking. Programs such as DockingApp (Di Muzio et al., 2017) and AUDocker LE (Sandeep et al., 2011) are somewhat similar (albeit less feature rich) open-source alternatives. Other GUI programs aim to simplify specific steps in the standard docking protocol. For example, MGLTools (http://mgltools.scripps.edu/), produced by the same group that created Vina, allows users to prepare ligand and receptor PDBQT files and to select an appropriate docking box. Popular molecular-visualization programs such as Chimera (Pettersen et al., 2004) and PyMOL (DeLano, 2002) also include plugins (both commercial and free) for setting up and visualizing Vina docking runs (Lill and Danielson, 2011;Seeliger and de Groot, 2010).
These tools are certainly useful, but they still require users to download and install separate executable files. Furthermore, some of these tools are costly, work on only some operating systems, and still suffer from usability despite their GUI implementations. In contrast, Webina works entirely in the browser on all operating systems and is as easy to use as visiting a standard web page.

Server Applications
Recognizing the advantages of web-based docking, others have created server-based web apps that allow users to perform Vina docking on remote computer resources. MTiOpenScreen (Labbé et al., 2015) is a good example of such an app. Though effective, the server-based approach requires app creators to maintain and secure the substantial remote resources needed to perform docking runs. Many users, especially those working in industry, may also be reluctant to upload their proprietary receptor and small-molecule structures to any third-party server. In contrast, Webina requires only one-way communication from the server to the browser. The browser downloads the Webina library just as it would an image or video. Webina then performs all docking calculations in the browser itself, without needing to transmit information about the docking input or output back to the server.