-Molecular docking and virtual screening experiments require large computational and data resources and high-level user interfaces in the form of science gateways. While science gateways supporting such experiments are relatively common, there is a clearly identified need to design and implement more complex environments for further analysis of docking results. This paper describes a generic framework and a related methodology that supports the efficient development of such environments. The framework is modular enabling the reuse of already existing components. The methodology is agile and encourages the input and participation of end-users. A prototype implementation, based on the framework and methodology, of a science-gateway-based molecular docking environment for recommending a ligand-protein pair for next docking experiment is also presented and evaluated.
I. INTRODUCTION Molecular docking is a computational simulation that models biochemical interactions to predict where and how two molecules would bind. Large-scale molecular docking simulations are used in areas such as drug discovery where they can decrease the amount of wet-lab experiments required. Since molecular docking uses the structure of the receptor, large-scale molecular docking of hundreds of thousands of ligands and one receptor is called structure-based virtual screening (virtual as opposed to the robotics-based high throughput screening). Although a single docking simulation is relatively short, a typical virtual screening experiment, that may combine thousands of simulations, is computationally demanding, requiring the use of Distributed Computing Infrastructures (DCIs). Utilising and accessing such computational resources adds an extra level of complexity to the task making it increasingly difficult for biomedical scientists. Science gateways are widely utilised in this area to help bridging this gap.
Although this field has seen great advancements recently,
feedback from biomedical scientists shows that there is still a
significant gap to bridge. Examples for science gateways
supporting molecular docking and virtual screening
experiments include several WS-PGRADE/gUSE [
This paper investigates such scenarios and proposes a generic conceptual framework to support the analysis of molecular docking results, and a related methodology that uses regular input from scientists when developing complex sciencegateway-based environments for the storage, analysis and reuse of molecular docking results. It has been developed considering biomedical scientists’ requirements collected from semi-structured interviews and a literature review of 14 related projects including those mentioned in the paragraph above. From this generic framework, specific architectures can be derived supporting various molecular-docking-related analytical scenarios as shown in Section II. Additionally, a software development methodology that supports creating docking experiments based on this framework is explained in Section III. Finally, a prototype implementation of such system is presented in Section IV.
II. GENERIC FRAMEWORK FOR THE ANALYSIS OF MOLECULAR
DOCKING RESULTS The aim of our research was to identify potential similarities in the work of biomedical scientists working with molecular docking experiments, and to investigate whether a generic framework for such application scenarios can be defined. The assumption was that based on this generic framework more specific science gateway based environments can be implemented supporting different application scenarios. As these scenarios have large similarity, deriving and implementing such specific environments can be speeded up significantly. In other words, the aim was to formalise and speed up the development of specific science gateway environments supporting various molecular docking scenarios. In order to identify typical user requirements, several interviews with five scientists from different backgrounds and with various degrees of experience with molecular docking simulations were conducted. Since the number of the interviewees was small and the population localised in London, this is a not a representative sample of the world-wide population of scientists that use molecular docking simulations. However, considering its diversity, the sample was useful in producing several conclusions. The interviews aimed at identifying requirements of the scientists when performing molecular docking experiments and specifying scenarios that are not supported by currently available science gateways for molecular docking. These scenarios typically represent software systems that make a decision based on the molecular docking results, mimicking the steps that a scientist needs to take after obtaining the results. Some representative and identified scenarios are listed below: 1. Suggest a ligand-protein pair that should be used in the next molecular docking, based on protein similarity and previous results 2. Filter docking results which are suitable for wet laboratory experiments, based on ligand properties 3. Find off-target drugs, based on deducing if the estimated binding is at an active site 4. Enable verification of the docking methodology and learning from previous docking for novice users 5. Compare results from different molecular docking tools Based on the conceptual similarities of these scenarios and an extended review of literature, a generic framework has been designed. The design focuses on the similar elements in the scenarios and includes the following components (see Figure 1): Molecular Docking Environment (MDE): All scenarios include an environment where the molecular docking simulation is executed. It could be as simple as running a single simulation from the command line on a local computer, to more complex such as executing a virtual screening experiment on a DCI. This environment includes the software tool used for the docking itself, and may also include additional elements to connect to a DCI or to provide a high level user interface.
Molecular Docking Results Repository (MDRR): After the execution of the molecular docking, the results need to be stored as previous molecular docking results are needed by various scenarios. The repository should also store information about the final decision made by the whole simulation environment.
Additional Tool (AT): The results which have been stored in the MDRR are then processed by an AT. This is a generic element that describes a tool which takes one or more molecular docking results as input and conducts a calculation. ATs can refer back to other molecular docking results stored in the MDRR, communicate with other ATs, or refer to data stored in an Additional Data Source.
Additional Data Source (ADS): It contains data that is relevant for the final decision and usually is an external database.
Decision Maker (DM): All the information processed from the various ATs is passed to a DM. This element groups and analyses the calculations performed by the ATs in order to make a decision.
The numbers in Figure 1 present the order or flow of events through the different elements: 1. A scientist uses an MDE to conduct the molecular docking and the result is uploaded to the MDRR. 2. The MDRR sends the results to one or more ATs. 3. An AT may communicate with one or more other ATs. 4. An AT may look up data stored in the ADS. 5. An AT may require additional previous molecular docking results as input for its calculation. 6. An AT would provide its calculation results to the DM. 7. The MDRR may use data from the ADS directly. 8. Previous results from the MDRR may be used by the DM 9. The DM may use data from the ADS directly. 10. Once the analysis is complete and the decision is made, it can be passed back to the MDRR. 11. Finally, the decision is passed to the MDE to visualise it. From this generic framework each specific scenario introduced earlier, and also the ones covered in the literature review can be derived. For illustration, a basic architecture diagram for the first scenario is shown in Figure 2. Similar figures for each scenario have been designed and analysed demonstrating that the framework is generic enough to support at least the five identified scenarios and the 14 related solutions covered in the literature. However, these figures are not presented here due to limitations in length of the paper. In Scenario 1 (Figure 2) the framework would analyse previous molecular docking results and look for good docking results that have used a receptor similar to the currently used receptor. Based on this, the system suggests a new proteinligand pair that would be an interesting candidate for docking. Two key issues here are the definitions of good docking result or similar receptor.
In Figure 2 the building blocks of the Generic Framework
have been replaced with concrete elements supporting this
particular scenario. One of the advantages of this modular
design is that these building blocks can be easily replaced with
other elements if necessary. This way multiple existing tools
can be integrated into the scenario design and evaluated,
requiring only the implementation of components that are not
currently available. Mapping of the generic framework for
this particular scenario in the presented example is as follows:
The MDE is an extended version of the popular Racoon2 [
Figure 2 – Basic diagram of scenario to suggest a ligandprotein pair for next docking (Scenario 1) The flow of events is shown in Figure 2. Raccoon2 executes the molecular docking and the results are uploaded to the MDRR (1). The MDRR sends the receptor pairs to DeepAlign (2). The results of DeepAlign are assessed by the custommade AT (3) that sends the results to the MDRR (4) and the DM (5). All past docking results of similar receptors are sent to be assessed (6) and the good results are sent to the DM. The DM combines the results from the ATs, and suggests which protein-ligand pair to dock as a next step. This suggestion is returned to the MDRR and stored as meta-data (8). Finally, it is presented to the user (9).
Based on the basic generic architecture of Figure 1, a more
detailed framework has been developed that consist of a
diagram, a textual description of elements and interfaces, and
a formal description using Z-notation [
The diagram representing the framework in Figure 3 is a generic model, showing all generic elements and all possible interfaces between them. It is based on the UML Component Diagram in the sense that the elements are drawn as components and the interfaces between them are the typical provided and required interface connections. Additionally, it features arrows pointing towards the direction of the flow of data in a particular interface.
User → MDE, provided by the MDE: allows the user to upload the correct input for the molecular docking or additional user input values needed by another element. MDE → user, provided by the MDE: displays the result of the molecular docking to the user, along with other results from the MDRR.
Following this, each element and each interface have been described formally using Z-notation. As the set of descriptions is too extensive for this paper, only a representative example is presented here, describing the MDE and its interfaces (see Figures 4 and 5).
The docking process expressed by the MDE needs a ligand,
receptor, and optionally configuration (config) files as input,
and provides a docking result file as output. When there is no
config file then the dockingWithoutConfig() function will
generate the docking result, while when there is a config file
then the dockingWithConfig() function will do it. Furthermore,
the Z-notation for dockingWithoutConfig() describes that for
every ligand × receptor pair, as long as the ligand and receptor
are not empty files, there exists a docking result. Similarly,
dockingWithConfig() defines that for each ligand and for each
receptor there exists a configuration file that can be used to
produce a docking result. The corresponding Z-notation
descriptions can be seen in Figure 4.
Based on the above detailed description of the generic
framework, a detailed architecture diagram of each scenario
can now be derived followed by the textual and formal
descriptions of these scenarios. Figure 6 shows part of the
detailed architecture diagram of Scenario 1, representing the
extended Raccoon2 as an MDE, and corresponding to that part
of the basic diagram of Figure 2. In Figure 7 the formal
description of this module is shown. (Please note that full
diagram and description are not provided due to limitation of
length, but has been produced.)
This section describes the methodology for developing
complex environments that reuse and analyse molecular
docking results. This methodology complements the
framework described in the previous section by explaining
how this framework can be used during development. It
clearly states the roles that are required and the specific
subprojects for which they need to collaborate. The methodology
is based on the seven principles identified by Cockburn [
Upon receiving this, Server 1 inserts a document in the analysis collection before initialising the DM and sending it the similar receptors and the good results. The DM combines these two lists into one and sorts it based firstly on the DeepScore value, then on the affinity. This enables users to view an ordered list of results that contain ligands which are suggested for a subsequent docking.
At the core of this custom-made MDRR is a MongoDB
database. There were several reasons why we chose this type
of non-relational database:
1. MongoDB’s schеma-less design is ideal because a single
collection can be used for: input files in different formats,
output files of any of the over 50 docking tools [
MongoDB scales very well for large amounts of data, provided it is well designed and features such as sharding and indexing are utilised.
MongoDB is well-suited for prototyping because it is
easier to change what is stored during development.
In this prototype implementation we have considered .pdbqt
molecules and AutoDock Vina results (as used by Raccoon2).
The ligands collection contains molecular properties
calculated using the OpenBabel and PyBel [
The results collection contains references to the ligand and receptor used, specific properties extracted from the result files (e.g. CPUs, random_seed), a list of the result models, each model containing affinity, rmsd_from_best, and the parsed model segment of the Vina result. The parsing process is simple – it stores all lines between MODEL and ENDMDL as elements of an array.
The framework was followed as described in Section II. A list of documented meetings and events is not presented with this paper, but serves as supporting evidence of following the methodology. The required roles were taken up by different researchers at the University of Westminster (with some doubling as multiple roles). The presented implementation proves that following the methodology such molecular docking framework can be implemented. Work is currently ongoing to quantify advantages when compared to more adhoc implementation.
Due to the Global Interpreter Lock (GIL), Python is not the optimal language for multi-threading without additional optimisations. Furthermore, Bottle uses a non-threading type of servers by default, so using a different specialised server would improve performance for simultaneous users. The number of items in the collections may become too big to be included in one zip file which is used to transfer data from servers and sending large files through the network could be a bottleneck. Finally, the current DM joins and sorts two lists without specific performance optimisations.
V. CONCLUSION AND FUTURE WORK This paper presented a generic framework and a corresponding methodology to implement complex science-gateway-based environments for the execution of molecular docking experiments extended with the intelligent analysis and utilisation of docking results. The framework incorporates a diagram, and textual and formal description enabling a modular design and the replacement and reuse of components. The methodology involves multiple stakeholders and requires their collaboration in an agile manner. In order to demonstrate the usability of the above, a scenario for suggesting a ligandprotein pair for next docking was also presented.
Future work includes the implementation and detailed evaluation of multiple scenarios to identify, and where possible quantify, the advantages provided by the framework and methodology. In order to achieve this, the implemented solutions are compared to state-of-the-art methods and environments to demonstrate the added value of our research.