schrodinger.stepper.app module

This module provides infrastructure for expanding a stepper workflow into an application for sharing and deploying with customers.

To use, subclass StepperApplication and implement the abstract methods (see the docstring for StepperApplication for more info). By using StepperApplication, you’ll be implementing an interface with other stepper applications making deployment and use of your stepper workflows much easier.

GLOSSARY

Constants dict: These are dictionaries providing values that are constant

within a deployment. These often define static/shared resources that are available to all compute nodes on a cluster.

User dict: Dictionaries defining user inputs and settings for a particular

workflow run. These often include parameters for how to run a workflow along with input files.

Configuration dict: Configuration dicts are the combination of a user

dict with a constants dict. They should define all information necessary to run the stepper application.

class schrodinger.stepper.app.StepperApplication

Bases: object

Base class for all stepper applications. To use, subclasses must implement the following abstract methods:

  • runWorkflow

  • deploymentCheck

  • setUpTestUserDict

  • writeConfiguration

The following methods are optional to implement but are highly recommended:

  • validate

  • getLocalInputFiles

  • getLocalInputFolders

See the docstrings of the individual methods to see what is expected for each.

Note that the docstrings for the abstract methods will be used as the help message for their associated subcommands (run/deployment_check/test/write_config)

After subclassing, you can expose your StepperApplication cmdline interface by creating a python file under $SCHRODINGER/python/scripts and setting get_job_spec_from_args and calling your app’s main method. This is better described through example:

# my_stepper_app.py
class MyApp(StepperApplication):
    ... # Implement abstract methods here.

get_job_spec_from_args = MyApp.get_job_spec_from_args
if __name__ == '__main__':
    MyApp.main()
classmethod validate(config_dict: dict)

Validate that the config_dict is properly configured. This is where subclasses will construct a stepper workflow and call validateSettings(). If there are any issues with the configuration, it’s expected that this method will raise an exception.

When the application is run as a job, validation will be run on the job-launching machine. The job itself will skip validation by default. If an application would like to validate during job execution, it’s free to call this method within runWorkflow.

NOTE::

This is a good place to call my_workflow.report() so users can see the topology of the workflow they will run.

Parameters

config_dict – The configuration dictionary to run the application. See the module glossary for more info.

classmethod runWorkflow(config_dict: dict)

This method does the actual running of the stepper workflow(s) associated with this stepper application.

Often times the workflows will generate output files that users are interested in. To add output files or folders to be brought back from a job run, use addOutputFile and addOutputFolder.

Parameters

config_dict – The configuration dictionary used for setting up and running the workflow. Usually includes settings and inputs.

classmethod deploymentCheck(constants_dict: dict)

This method checks that a particular deployment of this application is set up correctly. It’s expected that SAs will run this method on new deployments before beginning to run small tests.

Some potentially useful checks that can go here:

  • Confirm all static files noted in constants_dict exist

  • Confirm the license capacity of the license server

  • Confirm cloud service (aws/gcp) credentials are set up correctly

Parameters

constants_dict – Dictionary providing values that are constant within a deployment. These often define static/shared resources that are available to all compute nodes on a cluster.

classmethod setUpTestUserDict(constants_dict: dict, large=False)

This method is used to create a user_dict for starting a test run of the application. The user dict will be used in conjunction with constants_dict to create a configuration to start a test run.

Implementations of this method should be able to create both a user dict for both small and large runs. Small runs should ideally run in <30m but should still exercise as much functionality as possible of the workflow(s).

Parameters

  • constants_dict – Dictionary providing values that are constant within a deployment. These often define static/shared resources that are available to all compute nodes on a cluster.

  • config_fname – Where to write the configuration dict to.

classmethod writeConfiguration(user_dict: dict, constants_yaml: str, config_fname: str)

Given a user_dict and constants_dict, implementations of this method should write out a fully-fledged configuration file at config_fname.

Parameters

  • user_dict – Dictionary defining user inputs and settings for a particular workflow run.

  • constants_yaml – Filepath to yaml file providing values that are constant within a deployment. These often define static/shared resources that are available to all compute nodes on a cluster.

  • config_fname – Where to write the configuration dict to.

classmethod getLocalInputFiles(config_dict: dict) → Iterable[str]

Given a configuration dict, return the local input files required for workflow execution.

NOTE::

Static files should not be returned here.

Parameters

config_dict (dict) – The configuration dictionary used for setting up and running the workflow. Usually includes settings and inputs.

classmethod getLocalInputFolders(config_dict: dict) → Iterable[str]

Given a configuration dict, return the input folders required for workflow execution.

NOTE::

Static folders should not be returned here.

Parameters

config_dict (dict) – The configuration dictionary used for setting up and running the workflow. Usually includes settings and inputs.

classmethod get_job_spec_from_args(argv)
classmethod get_job_spec_builder_from_args(argv)

Implements the LaunchAPI method get_job_spec_from_args. Sets up a job to run on a host. If the user specifies --dry-run however, validation will be run instead and no job will be submitted.

Returns

JobSpecificationArgsBuilder or None

classmethod main(args=None)
classmethod parseArgs(args)
classmethod registerOutputFile(fname)
classmethod registerOutputFolder(dir_)
schrodinger.stepper.app.load_yaml(filename)
schrodinger.stepper.app.write_yaml(config_dict, filename)