Running Generative Glide from the Command Line
Generative Glide (formerly De Novo Virtual Screening) is a command-line workflow that is controlled by a single YAML configuration file, config.yaml. This topic describes how to generate a configuration file, run the workflow, and locate its input and output files. For a description of every configuration keyword, see Generative Glide Config File Keywords. You can also set up and run the workflow from Generative Glide - Hit Discovery (Beta) Panel.
Requirements
Generative Glide requires Glide, DeepAutoQSAR, and Active Learning access.
The workflow runs across several hosts:
| Host | Requirement |
|---|---|
| Driver | A non-preemptible node with enough disk space for the Bloom filter, intermediate files, and result files. |
| CPU host | CPUs with at least 4 GB RAM each. For best throughput, provide at least as many CPUs as the number of agents (for agent training) or the number of Glide tokens (for docking). |
| GPU host | At least one GPU, which is required to train the supervised model. |
Generating a Configuration File
The workflow is controlled by a config.yaml file. The easiest way to start is to generate a template and edit it. To generate a template with the most commonly used keywords, enter the following command:
$SCHRODINGER/run -FROM glide generative_glide.py get_settings
To generate a full template that includes all user-configurable keywords, add -verbose:
$SCHRODINGER/run -FROM glide generative_glide.py get_settings -verbose
Either command writes a config_template.yaml file with inline comments. Fill in your paths and targets, then rename or copy it to config.yaml. Because keywords can change between releases, generate a fresh template for the version you are running rather than reusing an old one. For a description of each keyword, see Generative Glide Config File Keywords and Generative Glide Target Property Keywords.
Running the Workflow
To run the full workflow, pass your configuration file with -config and specify the driver host with -HOST:
$SCHRODINGER/run -FROM glide generative_glide.py full_workflow -config config.yaml -HOST driverhost
For a help message summarizing all available command options, see the generative_glide.py Command Help topic, or enter the following command:
$SCHRODINGER/run -FROM glide generative_glide.py -h
Input Files
| Input | Description |
|---|---|
| Configuration file | A config.yaml file that specifies all workflow settings. |
| Glide grid file | A Glide receptor grid file (.zip or .grd) that defines the binding site for docking. Provide its path with the glide_grid_file keyword. This is the only structural input that is always required. |
| Prior model input | Either an existing prior model directory (or .zip/.gz archive), supplied with use_existing_prior_dir, or a SMILES dataset (.csv) to train a new prior, supplied with training_data. |
| Supervised model input | Either an existing model, supplied with use_existing_ml_model, or training data. By default the workflow samples molecules from the prior and docks them to build the model automatically. |
| Bloom filter file | A Bloom filter binary file (.bin) representing a commercial library, used to identify purchasable compounds. Provide its path with the library_bin keyword. Required only when in-library filtering is enabled. |
Output Files
All workflow files are saved in the directory named by the jobname keyword. The main outputs are listed below.
| Output | Description |
|---|---|
Generative_Glide_report_jobname.html
|
The main report, with the workflow status, analysis plots, a time breakdown, and a summary of the run. |
generated_molecules_jobname.csv
|
The generated molecules that pass the targets, with their SMILES and target property values, ranked by Glide docking score. |
| Glide pose files | The docked poses for the generated molecules, so you can visualize the pose for any molecule of interest. Pose titles use the InChIKey. The original generated SMILES, before LigPrep, is stored on each pose as the s_csv_source_smiles property, and appears as a source_smiles column in the Glide docking output file, so you can map a pose back to its generated structure. |
jobname.log
|
The log file, written to the directory from which you launched the job. |
The jobname directory also contains subdirectories for the intermediate results of each stage, including the prior model, the supervised model, the trained agents, and the generated samples with their analysis data.
Pre-trained Priors and Bloom Filters
You can train a prior model from your own SMILES dataset, or reuse a pre-trained one. Pre-trained prior models and matching Bloom filter files for major commercial libraries, such as Enamine REAL and WuXi GalaXi, are available through secure download links provided at the time of purchase. Contact help@schrodinger.com for help locating them.
A Bloom filter is a compact data structure for fast membership testing that identifies which generated molecules are already present in a commercial library. Build the Bloom filter from the same dataset used to train the prior model, so that in-library filtering is consistent with the chemical space the prior was trained on. To build a Bloom filter from your own compound set, see the help for the bloom_filter.py script:
$SCHRODINGER/run active_learning_dir/bloom_filter.py -h
Restarting the Workflow
The workflow is fully restartable. If a run is interrupted by a cluster failure, a timeout, or a cancellation, resubmit the same command with the same configuration file. On startup, the workflow checks for the output files of each stage. If a stage is already complete, it is skipped, and the workflow resumes from where it left off.
To rerun a stage without reusing its previous result, delete that stage's subdirectory in the jobname directory before resubmitting. Do not otherwise change the configuration file between restarts, because the workflow assumes the same configuration that created the directory.