Multi-instance GPU-based system for drug candidate discovery

Abstract

This system for drug candidate discovery comprises: a project management module that generates a project to which tasks for drug candidate discovery can be added; a simulation management module that generates a simulation, desired by a user, on the generated project; a simulation configuration module that configures a simulation flow, received as input from a user, for the simulation by using a simulation configuration area including a canvas area, a protein structure data input area, which includes one or more objects that can be dragged and dropped in the canvas area and changed into nodes, and a task module selection area; a simulation flow management module that manages information about nodes that can be executed earlier and later in the simulation flow configuration; and a simulation execution module that manages and executes tasks constituting the simulation flow by dividing and allocating GPU resources for each of the nodes.

Description

A multi-instance GPU-based system for discovering new drug candidates.

[0001] The disclosure relates to a system for discovering new drug candidates, and more specifically, to a multi-instance GPU-based system for discovering new drug candidates.

[0002] The discovery of new drug candidates is an early stage in drug development, and protein structure-based in silico screening methods are attracting attention. Protein structure-based in silico screening is a method for identifying potential new drug candidates from compound databases based on the three-dimensional structure of proteins to which the new drug candidate can bind. In silico refers to computer programming in computer simulations or virtual experiments. Protein structure-based in silico screening can predict the binding affinity of compounds by simulating the interactions between proteins and compounds. Protein structure-based in silico screening can identify compounds that precisely fit the active site of a protein, and can be useful for discovering compounds in novel chemical spaces, unlike ligand-based screening, which relies on known ligands and is limited in discovering entirely new chemical structures because it searches for compounds similar to existing ligands.

[0003] In the discovery of new drug candidates, there is a growing need to integrate big data analysis and artificial intelligence technologies with libraries of billions of compounds, utilizing a variety of analytical tools in parallel. To meet this demand, pharmaceutical research institutes and research institutes such as universities have been installing and operating various software. For example, the European Molecular Biology Laboratory (EMBL) has developed and offers downloadable tools for bioinformatics, or provides simple web applications.

[0004] However, these tools are provided without account creation, making them difficult for pharmaceutical companies demanding security to use. Data sharing between the tools is challenging, and they are installed on various operating systems such as Windows, Mac, and Linux, making consistent data management difficult. In this context, data analysis tools such as KNIME (Konstanz Information Miner) have emerged, attempting to visualize data processing in a flowchart format. However, most of these data analysis tools are installable, limiting accessibility. Furthermore, they are not specialized for new drug discovery, requiring significant effort and time to directly utilize them for the discovery of new drug candidates.

[0005] The task to be solved is to provide a new drug candidate discovery system that can precisely manage the GPU resources that users want to use in a customized manner in the discovery of new drug candidates.

[0006] According to one embodiment, a new drug candidate discovery system is implemented as a platform that provides users with functions or services necessary for discovering new drug candidates in the form of a web service, and may include: a project management module that creates a project in which tasks for discovering new drug candidates can be added; a simulation management module that creates a simulation desired by the user on the created project; a simulation setting module that sets a simulation flow for the simulation input by the user using a simulation setting area including a canvas area and a protein structure data input area and a task module selection area including one or more possible objects that can be changed into nodes by being dragged and dropped into the canvas area; a simulation flow management module that manages information on nodes that can precede or follow in the simulation flow setting; and a simulation execution module that manages and executes tasks for executing the simulation flow by dividing and allocating GPU resources by the nodes.

[0007] In some embodiments, the simulation execution module may include a task management module that schedules execution of the task using a task queue; and a GPU management module that manages GPUs based on a multi-instance GPU using a Docker container and executes the task scheduled by the task management module using a virtual GPU created based on the GPU.

[0008] In some embodiments, the new drug candidate discovery system may further include a task providing module that provides the task stored in the form of the Docker container to the simulation execution module.

[0009] In some embodiments, the task providing module may provide to the simulation execution module a first task that automatically finds an optimal docking site in a target protein structure, a second task that predicts an amino acid sequence into a protein 3-dimensional structure, a third task that analyzes and aligns actual binding energy (kcal / mol) and provides it to the user, a fourth task that converts kcal / mol to Kd / Ki (μM) for a selected ligand and compares and analyzes it, and a fifth task that receives a chemical structure of a ligand and predicts absorption, distribution, metabolism, excretion, and toxicity by assigning the task to the docker container.

[0010] In some embodiments, the new drug candidate discovery system may display a first user interface on the screen that receives input from the user the number of threads to be used to execute the task on the virtual GPU, and may display a second user interface on the screen that indicates the number of tokens required to be paid by the user to execute the task, the number of tokens increasing or decreasing according to the number of threads.

[0011] In some embodiments, the new drug candidate discovery system displays a screen that provides a user with a list of virtual GPUs, and the list may display a name that can identify the virtual GPU, information about a work module that can use the virtual GPU, and a maximum capacity supported by the virtual GPU.

[0012] In some embodiments, the new drug candidate discovery system displays a first screen that provides a list of servers to the user, and the list displayed on the first screen may display a name that can identify the server, information about a virtual GPU used by the server, information about a port used to connect to the server, the total capacity supported by the server, the remaining capacity of the server, and whether the server is available.

[0013] In some embodiments, the new drug candidate discovery system displays a second screen that provides the user with a list of the virtual GPUs used by the server, and the list on the second screen may display a name that can identify the server, GPU ID information for the virtual GPU used by the server, type information of the virtual GPU used by the server, the maximum capacity supported by the virtual GPU, the capacity currently available in the virtual GPU, and whether the virtual GPU is available for use.

[0014] In some embodiments, the new drug candidate discovery system displays a first screen that provides a user with a list of task queues, and the list on the first screen may display information on the position of a task inserted into the task queue, information on a URL that can be connected to the task, information on whether the task inserted into the task queue has been released, the name of the task inserted into the task queue, the ID of the task, and information on the number of threads used to execute the task.

[0015] In some embodiments, whether the job inserted into the job queue is executable is determined, and if it is determined to be executable, the job is executed, and whether the job is executable is determined by comparing the capacity occupied by the job when executed with the capacity currently available in the virtual GPU, and if the capacity occupied by the job when executed does not exceed the capacity currently available in the virtual GPU, the job is determined to be executable, and if the capacity occupied by the job when executed exceeds the capacity currently available in the virtual GPU, the job is determined to be unexecutable.

[0016] In some embodiments, the new drug candidate discovery system may display a second screen that provides the user with a list including information about the blocked capacity of the jobs scheduled in the job queue while they are being executed.

[0017] In some embodiments, the protein structure data input area includes one or more objects related to a function of uploading protein structure data, and the one or more objects may include objects that can be converted into one of a first node of a function of receiving protein structure data in the form of a PDB (Protein Data Bank) file from a user, a second node of a function of receiving protein structure data in the form of a PDB code from a user, a third node of a function of receiving protein structure data in the form of a protein sequence file from a user, and a fourth node of a function of receiving protein structure data in the form of a protein sequence from a user by dragging and dropping them onto the canvas area.

[0018] In some embodiments, the work module selection area includes one or more objects related to a function of performing detailed work on discovering new drug candidates based on uploaded protein structure data, and the one or more objects may be converted into one of a fifth node having a function of finding an optimal docking site in a target protein structure, a sixth node having a function of predicting an amino acid sequence into a protein 3-dimensional structure, a seventh node having a function of analyzing and aligning actual binding energy (kcal / mol) and providing it to a user, and an eighth node having a function of converting kcal / mol into Kd / Ki (μM) for a selected ligand and performing comparative analysis.

[0019] In some embodiments, the nodes that can precede the fifth node may include the first node, the second node, the third node, the fourth node, and the sixth node, and the nodes that can follow the fifth node may include the seventh node.

[0020] In some embodiments, the nodes that can precede the sixth node may include the third node, the fourth node, and the sixth node, and the nodes that can follow the sixth node may include the fifth node.

[0021] In some embodiments, a node that can precede the seventh node may include the fifth node, and a node that can succeed the seventh node may include the eighth node.

[0022] In some embodiments, the nodes placed in the canvas area are displayed with node connection shapes, and while the user clicks and holds the node connection shape displayed on the right side of a node, the color or shape of the node connection shape displayed on the left side of a node that can be connected among other nodes may be changed and displayed.

[0023] In some embodiments, the simulation flow management module may manage information for determining whether a connection is possible between the nodes through metadata.

[0024] According to the embodiments, the system provides optimized functions and a user interface for the discovery of new drug candidates. Previously, detailed tasks related to new drug candidate discovery were provided as separate, incompatible tools, making data sharing and consistent data management difficult. Furthermore, the system allows for easy management of simulation flows by creating, modifying, and deleting nodes. Furthermore, the GPU resources used to execute the generated simulation flows can be precisely and customarily managed.

[0025] Figure 1 is a block diagram illustrating a new drug candidate discovery system according to one embodiment.

[0026] Figures 2 to 6 are drawings showing exemplary screens of a new drug candidate substance discovery system according to one embodiment.

[0027] Figure 7 is a diagram showing an example of a simulation setting of a new drug candidate substance discovery system according to one embodiment.

[0028] Figure 8 is a block diagram showing a new drug candidate discovery system according to one embodiment.

[0029] Figures 9 and 10 are drawings showing an example of an implementation of a new drug candidate substance discovery system according to one embodiment.

[0030] Figures 11 to 14 are drawings showing an implementation example of a new drug candidate substance discovery system according to one embodiment.

[0031] Figures 15 to 22 are drawings showing an implementation example of a new drug candidate substance discovery system according to one embodiment.

[0032] FIG. 23 is a block diagram illustrating a computing device according to one embodiment.

[0033] Below, with reference to the attached drawings, embodiments of the present invention are described in detail so that those skilled in the art can easily implement the present invention. However, the present invention may be implemented in various different forms and is not limited to the embodiments described herein. In addition, in the drawings, parts irrelevant to the description are omitted for clarity of description, and similar parts are designated with similar reference numerals throughout the specification.

[0034] Throughout the specification and claims, whenever a part is said to "include" a certain component, this does not mean that it excludes other components, but rather that it may include other components, unless otherwise stated.

[0035] Additionally, terms such as “part,” “unit,” and “module” described in the specification may mean a unit capable of processing at least one function or operation described in the specification, which may be implemented by hardware, software, or a combination of hardware and software.

[0036] Figure 1 is a block diagram illustrating a new drug candidate discovery system according to one embodiment.

[0037] A new drug candidate discovery system (1) according to one embodiment may be implemented as a platform that provides users with functions or services necessary for discovering new drug candidates in the form of a web service. Specifically, the new drug candidate discovery system (1) may provide users with various functions or services, such as detecting and removing errors (or mistakes) in protein structure files without knowledge of other fields, enabling biologists with specific ideas for new drug development to utilize in silico screening methods, efficiently detecting and providing users with Enzymatically Active Pockets for Docking Calculation (EAPDC) from protein structures for docking, providing users with real-time rankings of candidate substances based on docking binding energy during a long-time docking simulation, increasing reliability by predicting docking binding energy in two stages, or enabling verification of discovered candidate substances through linkage with a verification company.

[0038] The new drug candidate discovery system (1) can provide the same functions or services to users in various environments using a web interface. Specifically, for example, some users may receive services from the new drug candidate discovery system (1) using a mobile device such as a smart phone or tablet computer running a mobile operating system, other users may receive services from the new drug candidate discovery system (1) using a laptop computer running a Windows operating system, and still other users may receive services from the new drug candidate discovery system (1) using a desktop computer running a Linux operating system. In other words, the new drug candidate discovery system (1) is implemented as a platform as a web service, allowing users in different environments to use the same functions or services required for calculating in silico candidate compounds using an artificial intelligence neural network and conducting preclinical experiments on new drug candidates, thereby enhancing compatibility and user convenience, and resolving various issues that required improvement in the in silico calculations previously performed through a terminal on Linux.

[0039] Referring to FIG. 1, a new drug candidate discovery system (1) according to one embodiment may include a project management module (10), a simulation management module (12), a simulation setting module (14), and a simulation flow management module (16).

[0040] The project management module (10) can create a project to which a series of tasks for discovering new drug candidates can be added. Furthermore, the project management module (10) can display the created project to a user via the display device of the computing device on which the new drug candidate discovery system (1) operates.

[0041] In some embodiments, the project management module (10) can perform project name encryption. For a project in which project name encryption is enabled, the project management module (10) can display the original, unencrypted project name to the user who created the project and users authorized to use the project, and display the encrypted project name to users who do not have the authorization to use the project. There is a concern that the project name may contain keywords related to the discovery of new drug candidates that must be kept secure. By preventing the project name from being exposed as is to users who are not participating in the same project, the security of the new drug candidate discovery system (1) used by multiple users can be enhanced. Enabling or disabling project name encryption can be done by changing the option settings not only when creating a project, but also after the project has been created.

[0042] In some embodiments, the project management module (10) may support project membership via invitation codes. For example, if a user creates a project, the user can send the invitation code to another user, and the other user who receives the invitation code can join the project by entering the invitation code. In other words, users can participate in projects created by others via invitation codes. Accordingly, users with diverse knowledge in various fields can participate in a single project to discover new drug candidates. In addition, the project management module (10) may support setting permissions for project members. For example, the project management module (10) may grant administrator permissions to specific members. Of course, the project management module (10) may also support users who are participating in a project to leave the project.

[0043] The simulation management module (12) can create a user-defined simulation on a project created by the project management module (10). A single simulation can include multiple task modules with detailed functions for performing new drug candidate discovery, and a single project can include multiple simulations. After creating a simulation, the user can upload protein structure data for performing the multiple task modules.

[0044] The simulation setting module (14) can display a simulation setting area (140) to the user via the display device of the computing device on which the new drug candidate discovery system (1) is driven when the user selects one or more simulations managed by the simulation management module (12). In the simulation setting area (140), the user can set the simulation flow so that the simulation desired by the user can be performed by arranging and connecting multiple work modules based on graph computing. In particular, the simulation setting area (140) can be laid out so that the user can see at a glance the function of uploading protein structure data and the work modules that perform detailed work related to new drug candidate discovery based on the uploaded protein structure data. This configuration can improve the problem that, in the past, detailed work related to new drug candidate discovery was provided as separate tools with low compatibility, making data sharing and consistent data management difficult. The simulation setting area (140) can include a protein structure data input area (142), a work module selection area (144), and a canvas area (146).

[0045] The protein structure data input area (142) may include one or more objects that can be dragged and dropped onto the canvas area (146). For example, the protein structure data input area (142) may include first to fourth objects. The first object may be converted into a first node by being dragged and dropped onto the canvas area (146), and the first node may receive protein structure data in the form of a PDB (Protein Data Bank) file from the user. The second object may be converted into a second node by being dragged and dropped onto the canvas area (146), and the second node may receive protein structure data in the form of a PDB code from the user. The third object may be converted into a third node by being dragged and dropped onto the canvas area (146), and the third node may receive protein structure data in the form of a protein sequence file from the user. The fourth object can be converted into a fourth node by dragging and dropping it into the canvas area (146), and the fourth node can receive protein structure data in the form of a protein sequence from the user.

[0046] The task module selection area (144) may also include one or more objects that can be dragged and dropped onto the canvas area (146). For example, the task module selection area (144) may include a fifth object to an eighth object. The fifth object may be converted into a fifth node by being dragged and dropped onto the canvas area (146), and the fifth node may perform a task of finding an optimal docking site in a target protein structure. In particular, the fifth node may use an artificial intelligence language model based on Natural Language Processing (NLP) to automatically find an active site in a target protein and generate an optimal docking grid box. In addition, the fifth node may automatically correct various errors that may exist in a protein structure file (i.e., a PDB file). That is, the fifth node can automatically detect and remove anisotropic B-factors from PDB files, detect alternative conformations in the amino acid residue field and correct them to non-alternative conformations, and detect unusual amino acids in the amino acid residue field and correct them to 20 types of non-specific amino acids. The sixth entity can be converted into the sixth node by dragging and dropping it into the canvas area (146), and the sixth node can predict amino acid sequences into protein tertiary structures. The seventh entity can be converted into the seventh node by dragging and dropping it into the canvas area (146), and the seventh node can analyze the actual binding energies (kcal / mol) and sort them in order of best to provide them to the user.That is, the seventh node can perform grid-based in silico docking based on the input protein structure, determine the chemical pose using LGA (Lamarckian Genetic Algorithm), and calculate the binding energy using the empirical scoring function. The eighth object can be converted into the eighth node by dragging and dropping it into the canvas area (146), and the eighth node can perform a comparative analysis by selecting the desired ligand and converting kcal / mol to Kd / Ki (μM). That is, the eighth node can predict the Kd / Ki value in μM using a CNN artificial intelligence model that has learned the protein-ligand structure and Kd / Ki / IC50 values.

[0047] The first to eighth objects can be converted into the first to eighth nodes by dragging and dropping them onto the canvas area (146), respectively. The user can freely arrange the first to eighth nodes onto the canvas area (146) in the desired execution order according to the purpose and environment of the simulation. In addition, the user can set the connection relationship between the first to eighth nodes arranged on the canvas area (146) through edges. The user can create a new drug candidate discovery simulation by arranging nodes and connecting edges between nodes. In addition, the user can clearly and easily manage information on protein structure data input by creating, changing, and deleting nodes in a simulation flow whose complexity increases as the number of nodes placed on the canvas area (146) increases and the number of edges between nodes increases.

[0048] In some embodiments, the simulation setting area (140) may further include an external module provision area (148). The external module provision area (148) may include a ninth entity that can be converted into a ninth node having any function provided externally to the new drug candidate discovery system (1) by dragging and dropping it into the canvas area (146). Accordingly, functions provided by other systems operating in conjunction with the new drug candidate discovery system (1) can be easily included in the simulation by setting a node in the canvas area (146).

[0049] As described above, the user can place and freely move nodes by clicking and dragging a desired object in the protein structure data input area (142), the work module selection area (144), and the external module provision area (148) and dropping it on the canvas area (146). In some embodiments, a node connection shape may be displayed on a node placed on the canvas area (146). While the user clicks and holds a node connection shape displayed on the right side of a node, the color or shape of the node connection shape displayed on the left side of a node that can be connected among other nodes may change. The user cannot establish a connection for a node whose color of the node connection shape displayed on the left side has not changed, and can establish a connection only for a node whose color of the node connection shape displayed on the left side has changed. Accordingly, the user can prevent the creation of an incorrect simulation flow by changing the color of the node connection shape without having to be aware of whether a causal relationship can be established between each node.

[0050] Information for determining whether a connection between nodes is possible can be managed by the simulation flow management module (16). The simulation flow management module (16) can manage information on nodes that can precede or follow in the simulation setup, and can use a separate data structure such as metadata as needed. In addition, the simulation flow management module (16) can also update information, such as by reflecting changes in information on nodes that can precede or follow in the metadata.

[0051] When a user wants to make a connection to another node whose color has changed in the node connection shape displayed on the left side while clicking and holding the node connection shape displayed on the right side of a node, the user can make a connection by clicking the node connection shape of a node and then clicking the node connection shape of another node, or by clicking and holding the node connection shape of a node and dragging it to the node connection shape of another node to make a connection. When the connection is completed, a connection line will appear between the nodes, and the connection between the nodes can be disconnected by clicking the X displayed on the connection line.

[0052] Objects included in the task module selection area (144) can be converted into nodes on the canvas area (146), and a run button can be created within the node. The user can click the run button to perform the task of the corresponding node. Before the task begins, the number of tokens required to perform the task is displayed, and upon user confirmation, the tokens are deducted and the task can be executed. When the task is completed, the run button changes to a result button, and a download button can be additionally created. The user can view the task execution results by clicking the result button, and can download the task execution results by clicking the download button.

[0053] In this way, by establishing the connection between nodes with individual functions in the discovery of new drug candidates, a simulation flow suitable for optimal compound development can be created. Furthermore, when functions are added internally or externally to the new drug candidate discovery system (1), nodes corresponding to the added functions can be created, facilitating the establishment of connections with existing nodes.

[0054] Figures 2 to 6 are drawings showing exemplary screens of a new drug candidate substance discovery system according to one embodiment.

[0055] Referring to FIG. 2, the simulation setting area (140) may include a protein structure data input area (142), a work module selection area (144), a canvas area (146), and an external module provision area (148). As illustrated, the protein structure data input area (142) may include one or more objects related to a function of uploading protein structure data, the work module selection area (144) may include one or more objects related to detailed work related to new drug candidate discovery performed based on the uploaded protein structure data, and the external module provision area (148) may include one or more objects related to any function provided externally. Such objects may be converted into nodes by being dragged and dropped by a user into the canvas area (146), and the nodes may be connected by edges to form a graph, which may represent the flow of the simulation. Of course, the number or types of objects included in the work module selection area (144), canvas area (146), and external module provision area (148) shown in the drawings are examples for the purpose of explaining the implementations, and the scope of the present invention is not limited to those shown.

[0056] Referring to FIG. 3, the protein structure data input area (142) may include a first entity (1420), a second entity (1421), a third entity (1422), and a fourth entity (1423). The first entity (1420), indicated as “PDB File Upload,” is related to a function of receiving protein structure data in the form of a PDB file, and the second entity (1421), indicated as “PDB Code Input,” is related to a function of receiving protein structure data in the form of a PDB code. The third entity (1422), indicated as “Protein Sequence File (Fasta),” is related to a function of receiving protein structure data in the form of a protein sequence file, and the fourth entity (1423), indicated as “Protein Sequence (File),” is related to a function of receiving protein structure data in the form of a protein sequence.

[0057] Meanwhile, the work module selection area (144) may include a fifth entity (1440), a sixth entity (1441), a seventh entity (1442), and an eighth entity (1443). The fifth entity (1440), indicated as "PocketFinder," is related to a function of automatically finding an optimal docking site, and the sixth entity (1441), indicated as "CaliciFold," is related to a function of predicting an amino acid sequence into a protein tertiary structure. The seventh entity (1442), indicated as "AI-Dock," is related to a function of automatically sorting the amino acid sequences in order of the best by analyzing the actual binding energy (kcal / mol), and the eighth entity (1443), indicated as "DeepCalici," is related to a function of converting kcal / mol into Kd / Ki (μM) and performing a comparative analysis.

[0058] In some embodiments, the fifth entity (1440) may detect and remove anisotropic B-factors from PDB files among protein structure data files input by the user, detect alternative conformations in the amino acid residue field and correct them to non-alternative conformations, and detect unusual amino acids in the amino acid residue field and correct them to 20 types of non-specific amino acids. For example, if a docking simulation is performed without removing anisotropic B-factors from the PDB file, an error may occur due to failure to recognize the PDB file format or failure to read the PDB file, and if a docking simulation is performed with alternative conformations or unusual amino acids in the amino acid residue field, an error may occur due to an unknown amino acid, which may result in a decrease in accuracy in performing the in silico screening method or an increase in the failure rate in discovering candidate substances. By automatically handling such error-causing factors, the user can prevent inefficiencies and inaccuracies that may arise from manual modification of PDB files, and can omit collaboration with structural biologists. In addition, the PDB file preprocessing process can be automatically handled internally without the user being aware of it, providing an environment in which the user can focus solely on discovering new drug candidates. In addition, in some embodiments, the fifth entity (1440) can perform corrections for missing residues in the protein structure of a PDB file. Specifically, the missing residues can be detected by examining the gaps between residues in the protein structure of the PDB file, and when the missing residues are found, a protein amino acid sequence suitable for completing the missing residues can be obtained through a sequence database search, and the missing residues can be automatically completed in the protein amino acid sequence thus obtained.Accordingly, subsequent work can be performed based on an error-free protein structure file from which errors that may occur during simulation have been removed.

[0059] The fifth entity (1440) can detect an Enzymatically Active Pocket for Docking Calculation (EAPDC) from a protein structure file to determine a docking calculation site. Specifically, the fifth entity (1440) can predict a docking site (i.e., EAPDC) in a target protein structure using an artificial intelligence language model. Specifically, the fifth entity (1440) calculates depth values ​​of a pocket based on a Solvent Accessible Surface (SAS) of a target protein surface, generates a Gradient Class Activation Map for amino acids that contributed in the process of predicting the activity of the target protein, and, considering the depth values ​​of the pocket and the values ​​for amino acids with high contributions in the Gradient Class Activation Map, can determine a site that has a high influence on the activity of the target protein as a docking calculation site. Here, the gradient class activation map may be extracted from a GCN (Graph Convolutional Network) trained using EC numbers (Enzyme Commission numbers) or GO numbers (Gene Ontology numbers), which are implemented as a natural language processing model embedding layer. Furthermore, the natural language processing model implemented as an embedding layer may be a Transformer natural language processing model.

[0060] Meanwhile, the external module provision area (148) includes a ninth entity (1480), and the ninth entity (1480) indicated as “CRO-Order” is related to the function of transmitting a verification request for a candidate substance desired by the user to the verification company server.

[0061] As illustrated in FIG. 3, for example, a user can drag and drop a first object (1420) marked as “Upload PDB File” into the canvas area (146), whereby it can be converted into a node (N31). The node (N31) can include a button that enables the function of inputting protein structure data in the form of a PDB file. In addition, the node (N31) can display related information such as the identifier of the corresponding node, the task execution status, etc. In addition, the node (N31) can include a button that can delete itself. As illustrated with the node (N31), the second object (1421) to the ninth object (1480) can be dragged and dropped into the canvas area (146) to be converted into nodes that display their own buttons, information, etc.

[0062] As illustrated in FIG. 4, a user can drag and drop a second object (1421) indicated as “Enter PDB Code” into the canvas area (146), whereby it can be converted into a node (N41). The node (N41) can include a button that enables a function of inputting protein structure data in the form of a PDB code. Subsequently, the user can drag and drop a fifth object (1440) indicated as “PocketFinder” into the canvas area (146), whereby it can be converted into a node (N42). The node (N42) can include a button that enables a function of automatically finding an optimal docking site.

[0063] As illustrated in FIG. 5, a node connection shape may be displayed on a node placed in the canvas area (146). Specifically, a node connection shape (CS1) may be displayed on the right side of a node (N51), and a node connection shape (CS2) may be displayed on the left side of a node (N52). While the user is clicking on the node connection shape (CS1) displayed on the right side of a node (N51), the color or shape of the node connection shape (CS1) displayed on the left side of a node (N52) that can be connected among other nodes may be changed. The user cannot establish a connection for a node whose color of the node connection shape displayed on the left side has not changed, and can establish a connection only for a node whose color of the node connection shape displayed on the left side has changed. While the user is clicking on the node connection shape (CS1) displayed on the right side of a node (N51), the color or shape of the node connection shape (CS1) displayed on the left side of a node (N52) that can be connected among other nodes can be changed based on information about preceding or succeeding nodes provided from the simulation flow management module (16).

[0064] As illustrated in FIG. 6, when you want to make a connection to another node (N62) whose color has changed in the node connection shape (CS2) displayed on the left side while clicking on the node connection shape (CS1) displayed on the right side of a node (N61), you can make a connection by clicking on the node connection shape (CS1) of a node (N61) and then clicking on the node connection shape (CS2) of another node (N62), or you can make a connection by clicking and dragging the node connection shape (CS1) of a node (N61) to the node connection shape (CS2) of another node (N62). When the connection is completed, a connection line is displayed between the nodes, and you can release the connection between the nodes by clicking on the X displayed on the connection line.

[0065] Figure 7 is a diagram showing an example of a simulation setting of a new drug candidate substance discovery system according to one embodiment.

[0066] Referring to Fig. 7, in an example of generating a simulation flow, nodes (N71) to (N74) are illustrated. The node connection shape on the right side of the node (N71) that receives protein structure data in the form of PDB code and the node connection shape on the left side of the node (N72) that automatically finds the optimal docking site are connected by an edge, the node connection shape on the right side of the node (N72) and the node connection shape on the left side of the node (N73) that analyzes and automatically aligns the actual binding energy (kcal / mol) are connected by an edge, and the node connection shape on the right side of the node (N73) and the node connection shape on the left side of the node (N74) that converts kcal / mol to Kd / Ki (μM) and performs a comparative analysis are connected by an edge. As explained above, the user cannot establish a connection for a node whose color of the node connection shape displayed on the left side has not changed among other nodes, and can establish a connection only for a node whose color of the node connection shape displayed on the left side has changed. Therefore, the user does not have to consider whether nodes can precede or follow each other in the discovery of new drug candidates, which increases convenience.

[0067] In some embodiments, information about possible preceding or succeeding nodes may be predetermined as follows.

[0068] Preceding NodesNodesFollowing NodesUpload PDB FilePocketFinderAI-DockInput PDB CodeProtein Sequence File (Fasta)Protein Sequence (Text)CaliciFoldProtein Sequence File (Fasta)CaliciFoldPocketFinderProtein Sequence (Text)PocketFinderAI-DockDeepCaliciAI-DockDeepCalici-

[0069] Nodes that can precede a node that automatically finds an optimal docking site ("PocketFinder") may include a node that receives protein structure data in the form of a PDB file ("Upload PDB File"), a node that receives protein structure data in the form of a PDB code ("Enter PDB Code"), a node that receives protein structure data in the form of a protein sequence file ("Protein Sequence File (Fasta)"), a node that receives protein structure data in the form of a protein sequence ("Protein Sequence (Text)"), and a node that predicts an amino acid sequence as a protein 3-dimensional structure ("CaliciFold"), and nodes that can follow it may include a node that automatically aligns amino acid sequences by analyzing actual binding energy (kcal / mol) ("AI-Dock"). Nodes that can precede a node that automatically finds an optimal docking site ("CaliciFold") may include a node that receives protein structure data in the form of a protein sequence file ("Protein Sequence File (Fasta)"), a node that receives protein structure data in the form of a protein sequence ("Protein Sequence (Text)"), and nodes that can follow it may include a node that automatically finds an optimal docking site. May contain a node ("PocketFinder").

[0070] A node that can precede a node that automatically sorts by analyzing actual binding energies (kcal / mol) ("AI-Dock") can include a node that automatically finds optimal docking sites ("PocketFinder"), and a node that can follow a node that converts kcal / mol to Kd / Ki (μM) and performs comparative analysis ("DeepCalici").

[0071] A node that can precede the node that performs comparative analysis by converting kcal / mol to Kd / Ki (μM) ("DeepCalici") may include a node that automatically sorts by analyzing the actual binding energy (kcal / mol) ("AI-Dock").

[0072] Information about such preceding or succeeding nodes can be managed by the simulation flow management module (16), and a separate data structure such as metadata can be used as needed. Furthermore, the simulation flow management module (16) can also update information, such as by reflecting changes in the information about preceding or succeeding nodes in the metadata. In this way, by establishing the connection relationship between nodes with each function in the discovery of new drug candidates, a simulation flow suitable for optimal compound development can be created.

[0073] Conventional simulation methods require complex simulations for new drug candidate discovery, requiring multiple trials in various ways. This requires significant effort, time, and cost, and has made satisfactory simulation setup difficult. The graph computing-based simulation setup method described in the examples improves upon conventional methods. As exemplified, it allows for the intuitive and easy creation and management of complex simulation flows, while also offering flexibility and convenience for easy modification. Furthermore, it enables the practical execution of highly complex and intricate simulation flows.

[0074] Figure 8 is a block diagram showing a new drug candidate discovery system according to one embodiment.

[0075] Referring to FIG. 8, a new drug candidate discovery system (1) according to one embodiment may include a simulation execution module (20), a job provision module (22), a docker container provision module (24), and a GPU (28), and a virtual GPU (GPU instance) (26) may be created based on the GPU (28).

[0076] The simulation execution module (20) can manage and execute tasks forming a simulation flow based on a simulation flow set by a user, which is provided from the simulation setting module (14). The simulation execution module (20) can include a task management module (201), a task queue (202), and a GPU management module (203).

[0077] The task management module (201) can schedule the execution of tasks for executing a simulation flow to be executed. Specifically, the task management module (201) inserts tasks for executing a simulation flow set by a user into a task queue (202) by dragging and dropping nodes representing task modules and connecting them based on graph computing, or deletes tasks included in the task queue (202) and executes tasks deleted from the task queue (202) using GPU resources. In some embodiments, the task queue (202) can be implemented as a FIFO (First In First Out) queue, but the scope of the present invention is not limited thereto, and the task queue (202) can be implemented in various forms using other data structures.

[0078] The GPU management module (203) manages the GPU (28) and, in cooperation with the Docker container provision module (24), can execute a task scheduled by the task management module (201) using the GPU (28). In particular, the GPU management module (203) can assign and execute a task to a GPU instance (26) created based on the GPU (28).

[0079] The task providing module (22) can provide detailed tasks for executing the simulation flow to the simulation execution module (20). Specifically, the task providing module (22) can provide the first task (221) to the fifth task (225) for performing new drug candidate discovery. The first task (221) is a task for automatically finding an optimal docking site in a target protein structure, and is illustrated as "PocketFinder." The first task (221) can correspond to a task instance created by converting an object displayed as "PocketFinder" by the user in the task module selection area (144) of the simulation setting area (140) into a node by dragging and dropping it into the canvas area (146). The second task (222) is a task for predicting an amino acid sequence into a protein tertiary structure, and is illustrated as "CaliciFold." The second task (222) may correspond to a task instance created by dragging and dropping an object marked as "CaliciFold" by the user in the task module selection area (144) of the simulation setting area (140) and converting it into a node on the canvas area (146). The third task (223) is illustrated as a task named "AI-Dock" that analyzes and sorts actual binding energies (kcal / mol) and provides them to the user. The third task (223) may correspond to a task instance created by dragging and dropping an object marked as "AI-Dock" by the user in the task module selection area (144) of the simulation setting area (140) and converting it into a node on the canvas area (146). The fourth task (224) is illustrated as a task named "DeepCalici" that converts kcal / mol to Kd / Ki (μM) for a selected ligand and performs comparative analysis.The fourth task (224) may correspond to a task instance created by dragging and dropping an object marked as "DeepCalici" by the user in the task module selection area (144) of the simulation setting area (140) and converting it into a node on the canvas area (146). The fifth task (225) is a task that receives the chemical structure of a ligand and predicts absorption, distribution, metabolism, excretion, and toxicity, and is illustrated as "ADME-Tox." The fifth task (225) may correspond to a task instance created by dragging and dropping an object marked as "ADME-Tox" by the user in the task module selection area (144) of the simulation setting area (140) and converting it into a node on the canvas area (146). That is, the task providing module (22) may provide an "instantiated task module" corresponding to an element of a simulation flow set for actual execution by being dragged and dropped by the user into the canvas area (146).

[0080] The GPU (28) may support multi-instance GPU (Multi-Instance GPU, hereinafter referred to as "MIG") technology. By supporting MIG, one GPU is divided into multiple independent virtual GPUs, and each of the multiple virtual GPUs created accordingly may be allocated its own memory, Compute Unified Device Architecture (CUDA) cores, and other resources. In some embodiments, a first virtual GPU (261) and a second virtual GPU (262) may be created based on the GPU (28). A value representing capacity may be set for the GPU (28). A value representing capacity may also be set for the virtual GPU (26), and a value representing capacity may also be set for each task (221, 222, 223, 224, 225). Here, the value representing the capacity of the virtual GPU (26) cannot be greater than the value representing the capacity of the GPU (28). And the capacity set for each task (221, 222, 223, 224, 225) can represent the capacity required for task execution.

[0081] The Docker container provision module (24) can provide one or more Docker containers (241, 242, 243, 244). The Docker containers (241, 242, 243, 244) can be used to independently allocate virtual GPUs to various tasks for performing new drug candidate discovery. Since the Docker containers (241, 242, 243, 244) are each executed in an independent environment, a problem occurring in one container (241) does not affect other containers (242), thereby ensuring security and stability. Meanwhile, since the Docker containers (241, 242, 243, 244) can be executed simultaneously, different tasks for performing new drug candidate discovery can be processed in parallel, thereby increasing scalability.

[0082] A single task for performing new drug candidate discovery can be assigned to a single Docker container. For example, a first task (221) that automatically finds an optimal docking site in a target protein structure can be assigned to a Docker container (241), a second task (222) that predicts a protein tertiary structure from an amino acid sequence can be assigned to a Docker container (242), and a third task (223) that analyzes and sorts actual binding energies (kcal / mol) and provides them to a user can be assigned to a Docker container (243). A fourth task (224) that converts kcal / mol to Kd / Ki (μM) for a selected ligand and performs comparative analysis can be assigned to a Docker container (244). And, for example, a Docker container (241) to which a first task (221) is assigned can be executed on a first virtual GPU (261), and a Docker container (242) to which a second task (222) is assigned can be executed on a second virtual GPU (262).

[0083] The operation flow of a new drug candidate discovery system (1) including a simulation execution module (20), a task provision module (22), a docker container provision module (24), and a GPU (28) may be as follows. The task management module (201) may insert at least one of the first task (221) to the fifth task (225) for new drug candidate discovery into the task queue (202) in the simulation flow provided from the simulation setting module (14). In some embodiments, the task management module (201) may obtain an “instantiated task module” as an item to be inserted into the task queue (202) from the task provision module (22) and insert it into the task queue (202). The status of the task inserted into the task queue (202) may be designated as a “waiting” status. Thereafter, the task management module (201) may delete the task waiting in the task queue (202) and request the GPU management module (203) to execute the corresponding task. The GPU management module (203) can execute a task requested to be executed by assigning it to the first virtual GPU (261) or the second virtual GPU (262). The status of a task that has started to be executed can be changed to the "running" status. The GPU management module (203) can block the virtual GPU to which the task is assigned and is being executed, thereby preventing other tasks from being assigned to the virtual GPU on which the task is already being executed, and can change information indicating available virtual GPUs.

[0084] Figures 9 and 10 are drawings showing an example of an implementation of a new drug candidate substance discovery system according to one embodiment.

[0085] Referring to FIG. 9, a new drug candidate discovery system (1) according to one embodiment may display a user interface (301) on the screen to receive input from a user the number of GPUs to be used to execute a simulation task for new drug candidate discovery. The user interface (301) may be displayed as “GPU threading count” and may allow the user to set an integer value using a + button or a - button. In a MIG-based GPU environment, the value set by the user interface (301) may represent the number of threads corresponding to a unit of data processed in a virtual GPU. For example, one virtual GPU core may be implemented to process one or more threads.

[0086] At the same time, the new drug candidate discovery system (1) according to one embodiment can display on the screen a user interface (302) that calculates and displays the number of tokens required to execute a simulation task for new drug candidate discovery from the user.

[0087] The new drug candidate discovery system (1) can be implemented to deduct tokens that users must pay for detailed tasks in simulations for new drug candidate discovery, or to allow users to recharge tokens by paying with coupons or other payment methods. Previously, there were no clear standards for the costs users had to pay for new drug candidate discovery by detailed task. Users paid the entire cost of new drug candidate discovery, not by detailed task. However, because the flow of detailed tasks in new drug candidate discovery varies depending on the discovery purpose and environment, users sometimes had to incur excessive costs regardless of the number and workload of detailed tasks actually performed. Furthermore, it was difficult to reflect exceptional circumstances, such as when a detailed task was interrupted mid-process, in the costs paid by users.

[0088] The new drug candidate discovery system (1) can determine the amount of tokens deducted for each detailed task for new drug candidate discovery. Specifically, the amount of tokens deducted can be determined by considering various factors related to the detailed task, such as the type of detailed task, the workload of the detailed task, and the difficulty of the detailed task. The token amount can be stored in a form readable by the computing device on a storage medium or cloud accessible by the computing device. The user can use the tokens based on criteria set according to the detailed task to be performed. In particular, as described above, by setting the connection relationship between nodes with each function in the new drug candidate discovery, a simulation flow suitable for optimal compound development can be created. The user can use the corresponding node by paying a token that is differentially applied to each node, and can pay only the amount of tokens needed for the node that is used.

[0089] In some embodiments, the amount of tokens deducted may be adjusted to decrease linearly or non-linearly depending on the progress of the subtask. Specifically, if a specific amount of tokens is defined for a specific subtask, that amount of tokens may be deducted when the subtask is completed, and if only a portion of the subtask is completed, only a portion of the tokens may be deducted. For example, tokens may be deducted only for the number of ligands the user specifies to analyze, or if the user interrupts or an error occurs during analysis, tokens may be deducted only for the amount of work up to the point of completion. Accordingly, while the discovery of new drug candidates typically requires a significant amount of cost, the user may be able to divide the cost by subtask or, if the subtask is not completed, may be able to bear only a portion of the cost.

[0090] The user interface (302) may display the text "Required Tokens" and the number of tokens required for the simulation task. In FIG. 9, the user is setting a simulation task for 2,115 ligands, and since the user interface (301) is set to 1, the user interface (302) may indicate that 2,115 tokens, which is the number of ligands in the case of, for example, an FDA-approved drug library, are required for the simulation task. In this case, the task shown in FIG. 9 may be performed in a single thread.

[0091] Referring to FIG. 10, the value of the user interface (301) may be changed to 2. For example, the user may increase the value of the user interface (301) using the + button to quickly obtain the results of the simulation task. Then, the user interface (302) may indicate that 4,230 tokens are required for 2,115 ligands. In the case of FIG. 9, if one thread is allocated to perform the simulation task for 2,115 ligands, in the case of FIG. 10, two threads are allocated and processed to perform the simulation task for 2,115 ligands, thereby reducing the task time by half.

[0092] In this way, users can directly decide how much GPU they will use for detailed tasks for discovering new drug candidates, and by paying a fee (token payment) based on the desired amount of GPU usage, users can have a choice in reducing calculation time and improving processing performance through GPU parallel computing without burdening them with excessive services and costs, and a reasonable cost system can be implemented.

[0093] Figures 11 to 14 are drawings showing an implementation example of a new drug candidate substance discovery system according to one embodiment.

[0094] Referring to FIG. 11, a new drug candidate discovery system (1) according to one embodiment can provide a user (e.g., an administrator) with a list of virtual GPUs on a screen (31). Specifically, the list can display a name that identifies the virtual GPU, information about a work module that can use the virtual GPU, and the maximum capacity (max capacity) supported by the virtual GPU. For example, the capacity can be expressed as the maximum capacity of RAM (MB) or as a numerical value proportional to the RAM.

[0095] For example, an item (311) in the list is displayed as "NVIDIA A100 - Excluding AIDock" and its "Maximum Capacity" is displayed as 40000. Here, the virtual GPU is identified by the name "NVIDIA A100", the task modules that can use the virtual GPU are all task modules except the "AI-Dock" task module, and the maximum capacity supported by the virtual GPU is 40000. Next, an item (312) is displayed as "NVIDIA A100 - AIDock Only" and its "Maximum Capacity" is displayed as 40000. Here, the virtual GPU is identified by the name "NVIDIA A100", the task modules that can use the virtual GPU are only the "AI-Dock" task module, and the maximum capacity supported by the virtual GPU is 40000. Next, item (313) is displayed as "NVIDIA A100" and "Maximum Capacity" is displayed as 40000. Here, the virtual GPU is identified by the name "NVIDIA A100", there is no limit to the work modules that can use the virtual GPU, and the maximum capacity supported by the virtual GPU is 40000.

[0096] Clicking on an item in the list that displays the name of a virtual GPU will take you to a page that provides details and allows you to edit it.

[0097] Referring to FIG. 12, a detailed page displayed when an item (311) is clicked is illustrated. Since the available work modules for "NVIDIA A100" are all work modules except for the "AI-Dock" work module, the "Capacity" item includes prep, admet, calici_fold, deep_calici, deep_calici_4dcnn, and deep_calici_resnet3d as work modules.

[0098] Prep represents a task module ("PocketFinder") that automatically finds optimal docking sites in a target protein structure. The memory footprint of Prep can be set to 10,000 MB on the virtual GPU. Accordingly, up to four Prep modules can be run simultaneously on an NVIDIA A100.

[0099] admet represents a task module ("ADME-Tox") that takes the chemical structure of a ligand as input and predicts its absorption, distribution, metabolism, excretion, and toxicity. admet can utilize the CPU instead of the GPU. Therefore, its capacity can be set to 0 MB. Although admet does not utilize the GPU, it must be included in the "Capacity" field with a capacity of 0 MB to run on the CPU.

[0100] calici_fold represents a working module ("CaliciFold") that predicts protein tertiary structures from amino acid sequences and can utilize the entire GPU memory. Therefore, the memory capacity occupied by calici_fold in the virtual GPU can be set to 40,000 MB.

[0101] deep_calici represents a task module ("DeepCalici") that converts kcal / mol to Kd / Ki (μM) for the selected ligand and performs comparative analysis. The memory capacity of deep_calici in the virtual GPU can be set to 20,000 MB. Accordingly, up to two deep_calici instances can be run simultaneously on "NVIDIA A100."

[0102] deep_calici_4dcnn and deep_calici_resnet3d represent a task module that compares and converts kcal / mol to Kd / Ki(μM) for ligands selected based on a 4D CNN model, and a task that compares and converts kcal / mol to Kd / Ki(μM) for ligands selected based on a ResNet 3D model, respectively. The capacity occupied by each virtual GPU memory can be set to 12,000 MB. Accordingly, up to three deep_calici_4dcnns or up to three deep_calici_resnet3ds can be run simultaneously on "NVIDIA A100".

[0103] Referring to FIG. 13, the detailed information page displayed when item (312) is clicked is illustrated. Since the only available working module for "NVIDIA A100" is the "AI-Dock" working module, the "Capacity" item includes only ai_dock as a working module.

[0104] ai_dock represents a working module ("AI-Dock") that analyzes and sorts actual binding energies (kcal / mol) and provides them to the user. The memory capacity of ai_dock in the virtual GPU can be set to 6,000 MB. Accordingly, up to six ai_docks can run simultaneously on an "NVIDIA A100."

[0105] And with respect to Fig. 12, prep, admet, calici_fold, deep_calici, deep_calici_4dcnn and deep_calici_resnet3d described above may not be included in the “capacity” item.

[0106] Referring to FIG. 14, the detailed information page displayed when item (313) is clicked is illustrated. Since there is no limitation on the available work modules for "NVIDIA A100", the "Capacity" item includes prep, admet, ai_dock, calici_fold, deep_calici, deep_calici_4dcnn, and deep_calici_resnet3d as work modules.

[0107] In this way, information about available virtual GPUs for new drug candidate discovery is provided to users, and users can configure and adjust the capacity for specific tasks based on the performance of each virtual GPU, enabling fine-grained GPU resource management. For example, if a specific task module is allocated excessive capacity considering the performance of a given virtual GPU, the processing speed of the simulation task may slow down. In such cases, the user (administrator) can resolve this issue by allocating a smaller capacity to that task module (e.g., changing the capacity value for ai_dock from 8,000 to 6,000).

[0108] Figures 15 to 22 are drawings showing an implementation example of a new drug candidate substance discovery system according to one embodiment.

[0109] Referring to FIG. 15, a new drug candidate discovery system (1) according to one embodiment can provide a user (e.g., an administrator) with a list of flask servers on a screen (32). Here, the flask server is a server driven by the flask web framework, and task modules for discovering new drug candidates may be stored in the form of docker containers within the flask server. That is, the first task (221) to the fifth task (225) described above with respect to the task providing module (22) of FIG. 8 as detailed tasks for executing the simulation flow may be stored in the flask server in a form allocated to docker containers (241, 242, 243, 244) provided by the docker container providing module (24). Of course, the flask server is only an implementation example, and the server in which task modules for discovering new drug candidates are stored may not necessarily adopt the flask framework, but may be implemented based on another framework. However, for the sake of clarity and convenience of explanation, this specification describes a Flask server that adopts the Flask web framework as a non-limiting representative implementation example.

[0110] The list can display the name that identifies the Flask server, information about the virtual GPU used by the Flask server, information about the port used to connect to the Flask server, the total capacity supported by the Flask server, the remaining capacity currently available to the Flask server, and whether the Flask server is available. Here, the total capacity supported by the Flask server can be calculated as the sum of the maximum capacities of all GPUs if the Flask server uses more than one virtual GPU.

[0111] For example, the item (321) in the list is indicated by the Flask server name "cal-tb01", the "cal-tb01" server can use two "NVIDIA A100"s, and the port number for connecting to the "cal-tb01" server can be 9999. And the total capacity and currently available capacity supported by the "cal-tb01" server are 80000 and 80000, respectively, and are indicated as currently available.

[0112] Clicking on an item in the list that displays the name of a Flask server will take you to a page that provides details about the Flask server and allows you to edit it.

[0113] Referring to FIG. 16, a detailed page that is displayed when an item (321) is clicked is illustrated. The upper part may display a user interface that displays to the user the IP address and port number that can connect to the flask server "cal-tb01" and whether the "cal-tb01" server is available and provides the user with the ability to change the information. The lower part may display a user interface that displays to the user the ID of the GPU used by the "cal-tb01" server, the type of the GPU, whether the GPU is available and whether the GPU can be deleted and provides the user with the ability to change the information. Here, it is shown that a virtual GPU "NVIDIA A100" with a GPU ID of 0 and a virtual GPU "NVIDIA A100" with a GPU ID of 1 are set.

[0114] Referring to FIG. 17, a new drug candidate discovery system (1) according to one embodiment can provide a user (e.g., an administrator) with a list of GPUs used by a flask server on a screen (33). The list can display a name that can identify the flask server, GPU ID information for the GPU used by the flask server, type information for the GPU used by the flask server, the maximum capacity supported by the GPU, the currently available capacity of the GPU, and whether the GPU is available. For example, it can be seen that the "cal-tb01" server uses a virtual GPU "NVIDIA A100" whose GPU ID is set to 0, and whose maximum capacity and currently available capacity are each 40000, and a virtual GPU "NVIDIA A100" whose GPU ID is set to 1, and whose maximum capacity and currently available capacity are each 40000.

[0115] Referring to FIG. 18, a new drug candidate discovery system (1) according to one embodiment can provide a user (e.g., an administrator) with a list of task queues (202) on a screen (34). The list can display information on the position of a task inserted into the task queue (202), URL information that can be linked to the task, information on whether the task inserted into the task queue (202) has been released, the name of the task inserted into the task queue (202), the ID of the task, and information on the number of threads used to execute the task.

[0116] For example, the task corresponding to position 0 in the task queue (202) may not be released because it is waiting and has not yet been executed, the name of the task may be "PocketFinder", the ID of the task may be "615", and the number of threads used to execute the task may be 1. The task corresponding to position 1 in the task queue (202) may not be released because it is waiting and has not yet been executed, the name of the task may be "Ai-Dock", the ID of the task may be "617", and the number of threads used to execute the task may be 4. The task corresponding to position 2 in the task queue (202) may not be released because it is waiting and has not yet been executed, the name of the task may be "DeepCalici", the ID of the task may be "618", and the number of threads used to execute the task may be 1.

[0117] Here, the execution order may be determined based on the position within the task queue (202). For example, first, whether the task corresponding to position 0 is executable is determined, and if it is determined to be executable, the task may be executed. If the task corresponding to position 0 is executed, the task corresponding to position 0 may be marked as released. If the task corresponding to position 0 is determined to be unexecutable, the execution of the task corresponding to position 0 may be omitted. In this case, the task corresponding to position 0 may still be marked as not released.

[0118] Next, whether the task corresponding to position 1 is executable is determined, and if it is determined to be executable, the task can be executed. If the task corresponding to position 1 is determined to be inexecutable, the execution of the task corresponding to position 1 may be omitted. Next, whether the task corresponding to position 2 is executable is determined, and if it is determined to be executable, the task can be executed. If the task corresponding to position 2 is determined to be inexecutable, the execution of the task corresponding to position 2 may be omitted.

[0119] Here, whether the task is executable can be implemented in a way that, for example, the capacity occupied by the task when executed is compared with the capacity currently available on the GPU, and if the capacity occupied by the task when executed does not exceed the capacity currently available on the GPU, the task is determined to be executable, and if the capacity occupied by the task when executed exceeds the capacity currently available on the GPU, the task is determined to be unexecutable.

[0120] For example, if a Flask server includes two virtual GPUs, it can be assumed that the current available capacity of the first virtual GPU is 2,000 and the current available capacity of the second virtual GPU is 14,000. And it can be assumed that jobs with IDs 615, 617, and 618, as illustrated in FIG. 18, are inserted into the job queue (202). The job with ID 615 has a name of "PocketFinder," has a position 0 in the job queue (202), has 1 thread running, and if the capacity occupied by one thread is 10,000, a total capacity of 10,000 may be required for execution. Next, if a task with an ID of 617 is named "Ai-Dock", has position 1 in the task queue (202), has 4 threads running, and 6,000 capacity occupied by one task, it may require a total capacity of 24,000 to execute. Next, a task with an ID of 618 is named "DeepCalici", has position 2 in the task queue (202), has 1 thread running, and 20,000 capacity occupied by one task, it may require a total capacity of 20,000 to execute.

[0121] In this case, only the task with ID 615 may be determined to be executable on the second virtual GPU. If the task is executed on the second virtual GPU, the current available capacity of the second virtual GPU will decrease from 14,000 to 4,000. Since no task was executed on the first virtual GPU, the current available capacity will remain at 2,000. Meanwhile, the tasks with ID 617 and ID 618 will wait in the task queue (202).

[0122] As another example, it can be assumed that the current available capacity of the first virtual GPU is 40,000, and the current available capacity of the second virtual GPU is 40,000. In addition, it can be assumed that jobs with IDs 615, 617, and 618, as illustrated in FIG. 18, are inserted into the job queue (202). As previously discussed, jobs with IDs 615, 617, and 618 may require capacities of 10,000, 24,000, and 20,000, respectively.

[0123] In this case, the job with ID 615 is determined to be executable on the first virtual GPU, and will run and take up 10,000 of capacity, so the current available capacity of the first virtual GPU will decrease to 30,000. Next, the job with ID 617 is determined to be executable on the first virtual GPU, and will take up 24,000 of capacity, so the current available capacity of the first virtual GPU will decrease to 6,000. Next, the job with ID 618 is determined to be executable on the second virtual GPU, not on the first GPU, and will take up 20,000 of capacity, so the current available capacity of the second virtual GPU will decrease to 20,000. Ultimately, the current available capacity of the first virtual GPU will become 6,000, and the current available capacity of the second virtual GPU will become 20,000. And all jobs with IDs 615, 617 and 618 will be marked as released, and the job queue (202) will be empty. Fig. 19 shows a screen (34) displaying a list for the job queue (202) after all jobs with IDs 615, 617 and 618 have been executed.

[0124] Referring to FIG. 20, a new drug candidate discovery system (1) according to one embodiment can provide a user (e.g., an administrator) with a list including information about blocked capacity (i.e., capacity being used by a task) while a task scheduled in a task queue (202) is being executed, on a screen (35). The list can display information about the name of the flask server on which the task is being executed, ID information of the GPU on which the task is being executed on the flask server, information about blocked capacity that is being used by the task and therefore cannot be allocated to another task, ID information of the task being executed, and information about the number of the tasks being executed.

[0125] For example, on server "cal-tb01", the blocked capacity on the virtual GPU with GPU ID 0 may be 24000 as 4 threads of a job with ID "617" are running. Also, on server "cal-tb01", the blocked capacity on the virtual GPU with GPU ID 0 may be 10000 as 1 thread of a job with ID "615" is running. Also, on server "cal-tb01", the blocked capacity on the virtual GPU with GPU ID 1 may be 20000 as 1 thread of a job with ID "618" is running. The blocked capacity may be released after the jobs have completed execution.

[0126] Referring to Fig. 21, while the task is running, it can be confirmed that the currently available capacity of the virtual GPU whose GPU ID is designated as 0 used by the Flask server in the screen (33) described above with respect to Fig. 17 has decreased from 40000 to 6000. In addition, it can be confirmed that the currently available capacity of the virtual GPU whose GPU ID is designated as 1 has decreased from 40000 to 20000.

[0127] Referring to Fig. 22, while the task is running, it can be seen that the currently available capacity in the flask server has decreased from 80000 to 26000 in the screen (32) described above with respect to Fig. 15.

[0128] FIG. 23 is a block diagram illustrating a computing device according to one embodiment.

[0129] Referring to FIG. 23, a new drug candidate substance discovery system according to embodiments can be implemented using a computing device (50).

[0130] The computing device (50) may include at least one of a processor (501), a memory (502), a storage device (503), a display device (504) communicating via a bus (509), a network interface device (505) providing a connection to a network (40) for communication with other entities, and an input / output interface device (506) providing a user input interface or a user output interface. Of course, the computing device (50) may additionally include any electronic device necessary to implement the technical ideas described herein, although not illustrated in FIG. 23.

[0131] The processor (501) may be implemented in various types such as an Application Processor (AP), a Central Processing Unit (CPU), a Graphic Processing Unit (GPU), a Neural Processing Unit (NPU), etc., and may be any electronic device that executes a program or command stored in a memory (502) or a storage device (503). In particular, the processor (501) may be configured to implement the functions or methods described above with respect to FIGS. 1 to 22, and in relation to the new drug candidate substance discovery system according to embodiments of the present invention, artificial intelligence-specific calculations may be processed on a GPU or NPU.

[0132] The memory (502) and the storage device (503) may include various types of volatile or non-volatile storage media. For example, the memory (502) may include a read-only memory (ROM) or a random access memory (RAM), and the memory (502) may be located inside or outside the processor (501) and may be connected to the processor (501) through various known means. Meanwhile, examples of the storage device (503) include a hard disk drive (HDD) or a solid state drive (SSD), and the scope of the present invention is not limited to the elements listed above for explanation.

[0133] The new drug candidate discovery system according to the embodiments may be implemented as a program or software running on a computing device (50), and such a program or software may be stored on a computer-readable medium.

[0134] Meanwhile, the new drug candidate substance discovery system according to the embodiments may be implemented using the hardware of the computing device (50), or may be implemented as separate hardware that can be electrically connected to the computing device (50).

[0135] The embodiments described thus far provide optimized functionality and a user interface for the discovery of new drug candidates. This improves upon the difficulties previously encountered in data sharing and consistent data management due to the separate, incompatible tools used for detailed tasks related to new drug candidate discovery. Furthermore, the simulation flow can be easily managed by creating, modifying, and deleting nodes. Furthermore, the GPU resources used to execute the simulation flow can be precisely and customarily managed by the user.

[0136] Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements made by those skilled in the art to which the present invention pertains using the basic concept of the present invention defined in the following claims also fall within the scope of the present invention.

Claims

1. A new drug candidate discovery system implemented as a platform that provides users with functions or services necessary for discovering new drug candidates in the form of a web service. A project management module that creates projects where you can add tasks to carry out the discovery of new drug candidates; A simulation management module that creates a simulation desired by the user on the generated project; A simulation setup module for setting a simulation flow for the simulation, which is input from a user using a simulation setup area including a canvas area, a protein structure data input area including one or more possible objects that can be changed into nodes by dragging and dropping onto the canvas area, and a task module selection area; A simulation flow management module that manages information about nodes that can precede or follow in the above simulation flow settings; and A simulation execution module that manages and executes tasks for executing the simulation flow by dividing and allocating GPU resources by node. New drug candidate discovery system.

2. In paragraph 1, The above simulation execution module, A task management module that schedules the execution of the above task using a task queue; and A new drug candidate discovery system comprising a GPU management module that manages GPUs based on multi-instance GPUs using a Docker container and executes the tasks scheduled by the task management module using a virtual GPU created based on the GPU.

3. In paragraph 2, A new drug candidate discovery system further comprising a task providing module that provides the task stored in the form of the above Docker container to the above simulation execution module.

4. In paragraph 3, The above task providing module, A new drug candidate discovery system that provides to the simulation execution module a first task of automatically finding an optimal docking site in a target protein structure, a second task of predicting an amino acid sequence as a protein 3-dimensional structure, a third task of analyzing and aligning actual binding energy (kcal / mol) and providing it to the user, a fourth task of converting kcal / mol to Kd / Ki (μM) for a selected ligand and comparing and analyzing it, and a fifth task of inputting a chemical structural formula of a ligand and predicting absorption, distribution, metabolism, excretion, and toxicity.

5. In paragraph 1, A first user interface is displayed on the screen for receiving input from the user about the number of threads to be used to execute the above task on the virtual GPU, A new drug candidate discovery system, which displays a second user interface on the screen indicating the number of tokens required to be paid by the user to execute the task, which increases or decreases according to the number of threads.

6. In paragraph 1, Display a screen that provides the user with a list of virtual GPUs, The above list is a new drug candidate discovery system that displays a name that can identify the virtual GPU, information about a work module that can use the virtual GPU, and the maximum capacity supported by the virtual GPU.

7. In paragraph 1, Display a first screen that provides the user with a list of servers, A new drug candidate discovery system in which the list displayed on the first screen displays a name that can identify the server, information about a virtual GPU used by the server, information about a port used to access the server, the total capacity supported by the server, the remaining capacity currently available on the server, and whether the server is available.

8. In paragraph 7, Display a second screen that provides the user with a list of the virtual GPUs used by the server; A new drug candidate discovery system in which the list of the second screen displays a name that can identify the server, GPU ID information for the virtual GPU used by the server, information on the type of the virtual GPU used by the server, the maximum capacity supported by the virtual GPU, the capacity currently available in the virtual GPU, and whether the virtual GPU is available.

9. In paragraph 1, Display a first screen that provides the user with a list of work queues, A new drug candidate discovery system, wherein the list of the first screen displays information on the position of a task inserted into the task queue, information on a URL that can be connected to the task, information on whether the task inserted into the task queue has been released, the name of the task inserted into the task queue, the ID of the task, and information on the number of threads used to execute the task.

10. In paragraph 9, The task inserted into the above task queue is judged to be executable, and if it is judged to be executable, the task is executed. A new drug candidate discovery system, wherein the feasibility of the above task is determined by comparing the capacity occupied by the task when executed with the capacity currently available in the virtual GPU, and determining that the task is feasible if the capacity occupied by the task when executed does not exceed the capacity currently available in the virtual GPU, and determining that the task is not feasible if the capacity occupied by the task when executed exceeds the capacity currently available in the virtual GPU.

11. In paragraph 9, A system for discovering new drug candidates, which displays a second screen that provides a user with a list containing information about the blocked capacity while the tasks scheduled in the task queue are being executed.

12. In paragraph 1, The above protein structure data input area includes one or more entities related to the function of uploading protein structure data, A new drug candidate discovery system, wherein the one or more objects can be converted into one of a first node having a function of receiving protein structure data in the form of a PDB (Protein Data Bank) file from a user, a second node having a function of receiving protein structure data in the form of a PDB code from a user, a third node having a function of receiving protein structure data in the form of a protein sequence file from a user, and a fourth node having a function of receiving protein structure data in the form of a protein sequence from a user by dragging and dropping them onto the canvas area.

13. In paragraph 12, The above task module selection area includes one or more entities related to the function of performing detailed tasks related to the discovery of new drug candidates based on the uploaded protein structure data. A new drug candidate discovery system, wherein the one or more objects can be converted into one of a fifth node having a function of finding an optimal docking site in a target protein structure by dragging and dropping them onto the canvas area, a sixth node having a function of predicting an amino acid sequence into a protein 3-dimensional structure, a seventh node having a function of analyzing and aligning actual binding energy (kcal / mol) and providing it to a user, and an eighth node having a function of converting kcal / mol into Kd / Ki (μM) for a selected ligand and performing comparative analysis.

14. In paragraph 13, Nodes that can precede the fifth node include the first node, the second node, the third node, the fourth node, and the sixth node, A new drug candidate discovery system, wherein a node that can follow the fifth node includes the seventh node.

15. In paragraph 13, Nodes that can precede the sixth node include the third node, the fourth node, and the sixth node, A new drug candidate discovery system, wherein the node that can follow the sixth node includes the fifth node.

16. In paragraph 13, The nodes preceding the seventh node include the fifth node, A new drug candidate discovery system, wherein a node that can follow the seventh node includes the eighth node.

17. In paragraph 1, The node placed in the above canvas area displays a node connection shape, A new drug candidate discovery system in which, while a user clicks on a node connection shape displayed on the right side of a node, the color or shape of a node connection shape displayed on the left side of a node that can be connected among other nodes changes and is displayed.

18. In paragraph 17, The above simulation flow management module is a new drug candidate discovery system that manages information for determining whether a connection between the nodes is possible through metadata.

Images