Web‐accessible molecular modeling with Rosetta: The Rosetta Online Server that Includes Everyone (ROSIE)

Abstract

The Rosetta molecular modeling software package provides a large number of experimentally validated tools for modeling and designing proteins, nucleic acids, and other biopolymers, with new protocols being added continually. While freely available to academic users, external usage is limited by the need for expertise in the Unix command line environment. To make Rosetta protocols available to a wider audience, we previously created a web server called Rosetta Online Server that Includes Everyone (ROSIE), which provides a common environment for hosting web‐accessible Rosetta protocols. Here we describe a simplification of the ROSIE protocol specification format, one that permits easier implementation of Rosetta protocols. Whereas the previous format required creating multiple separate files in different locations, the new format allows specification of the protocol in a single file. This new, simplified protocol specification has more than doubled the number of Rosetta protocols available under ROSIE. These new applications include pK _a determination, lipid accessibility calculation, ribonucleic acid redesign, protein‐protein docking, protein‐small molecule docking, symmetric docking, antibody docking, cyclic toxin docking, critical binding peptide determination, and mapping small molecule binding sites. ROSIE is freely available to academic users at http://rosie.rosettacommons.org.

Introduction

Rosetta is a molecular modeling suite which provides a wide array of tools for prediction and design of biological macromolecules. Rosetta has been used in a number of diverse publications, from prediction of protein structure,1 ribonucleic acid (RNA) structure,2 protein–protein interactions,3, 4 protein–peptide interactions,5, 6 and protein–small molecule interactions,7, 8 to the use of nuclear magnetic resonance9, 10 and electron density information11, 12 in structure prediction and refinement, to the design of novel protein folds,13, 14 protein–protein interactions,15, 16 protein–small molecule interactions,17, 18 enzymes,19, 20 macromolecular cages,21, 22 and protein–interacting peptides.23

Rosetta is maintained by the RosettaCommons, a collaborative association of more than 45 principal investigators and collaborators at 55 institutions. With over 350 active developers and a modular architecture,24 new protocols and functionality are continually being added. While recent efforts have expanded the usability of Rosetta with interfaces to Python (PyRosetta25), and XML (RosettaScripts26), and the publication of introductory tutorials,27, 28, 29 most of Rosetta's functionality still requires familiarity with the Unix command line environment, limiting use by nonexperts.

Web‐accessible servers are one way to lower the barrier for nonspecialist users to access Rosetta protocols. Indeed, many groups creating Rosetta protocols have independently implemented servers making their protocols available to anyone with an internet connection and a web browser.30, 31, 32, 33, 34 Unfortunately, setting up a new scientific web server is a laborious process, one which introduces a significant “barrier to entry” for exposing new protocols. To reduce the complexity of setting up a new web server, we have previously implemented Rosetta Online Server that Includes Everyone (ROSIE), a single server framework which can accommodate a range of Rosetta protocols.35

Here, we describe an improvement to the application program interface (API) for the ROSIE framework. This “meta” API simplifies the process of taking a protocol implemented in the Unix command line and converting it to a web‐accessible server. This simplified API has permitted Rosetta developers to more than double the number of protocols exposed through ROSIE since the previous publication. It should also facilitate user requests for additional Rosetta protocols to be exposed through the ROSIE interface.

Results

Our previous paper35 has already described the general ROSIE server architecture, including the structure of the database and servers. The primary improvement over the previous approach is a simplified method for specifying new protocols. This new meta API acts as a domain‐specific mini‐language, where input and output facilities are specified through object specification (“widgets”) and the execution is specified through a list of “triggers.” An example of the meta application specification format can be found in the Supporting Information.

Overview of simplified protocol definition

In contrast to the previously published method of implementing a ROSIE protocol, which required multiple different files in defined locations,35 ROSIE protocols can now be implemented within a single Python file located in the rosie.front/rosie/meta/directory of the ROSIE server. This file contains declarations of all the relevant contents of the submission, results and documentation pages on the ROSIE website, as well as the specification of how to run the protocol. These contents are contained within a “named tuple” (NT) object in the Python file.

Submission form definition

The format of the submission form (Fig. 1) is described by the “input_” data member of the NT. This member contains a list of the various input elements from which the form can be constructed. The input elements are represented as Python objects, with different input types being a different subclass of the “Input” widget class (Table 1). Each different input widget contains the html and javascript code needed for proper display of the input field on the submission page. A protocol developer need only to specify the widget type and relevant parameters: for example,

Figure 1.

ROSIE input elements. A: Example of a submission form. B: Example of the FileInput widget, customized for structure file loading. C: Example of the FileInput widget, after file selection. Icons of the submitted structures are shown. D: Example of the CheckboxInput and FloatInput widgets.

Table 1.

Input Widgets

Input widget	Description
FileInput	Upload an arbitrary input file
StringInput	An arbitrary text string
IntInput	An integer in a specified range
FloatInput	A real number in a specified range
CheckboxInput	True/False option input
SelectInput	Pick one of several specified options, in dropdown format
RadioButtonListInput	Pick one of several specified options, in selection list format
HRuleInput	No input, but add a separator to the input page

[FloatInput(name=‘pocket_width’, min=0.0, max=7.0, default=5.0, description=‘Maximum radius to search (in Angstroms) from starting coordinate’, optional=True)]

From the list of input elements, the submission form is built automatically, placing the desired input elements one after each other on the page. Additional input elements common to all protocols, such as job descriptions and account information, are handled by the ROSIE server framework and do not need to be explicitly included by the protocol writer.

Validation of input

As the input parameters are entered by potentially untrusted users on the internet, it is critical that any values that are entered are checked and validated to make sure that they are in the proper form and do not contain any malicious content. Misplaced punctuation or deliberately crafted input could compromise the integrity of the server. Additionally, as the aim of the web server is to provide access to protocols to people with limited modeling experience, it is important to check the range of the input parameters, to make sure that they will not produce anything that is compromised scientifically.

To that end, all input fields in ROSIE contain a validation component. While certain fields (such as numeric entry) can be checked automatically by the input widget to ensure they are correctly formatted and are in the appropriate range, other fields (such as structure file uploads) require special attention to ensure they are correctly formatted. To allow for custom validation, each input widget accepts a list of validators, which are Python functions. These validators can signal an improper input value by raising a Python exception.

As combinations of input values may also be inappropriate, rather than input values in isolation, the ROSIE framework also provides an “input_validator” entry, which is a Python function that will be passed all of the values in the input form. This validator may perform any comparisons the protocol author deems necessary and signal an improper value by returning an error message string.

Execution of the protocol

Protocol execution is specified in the “commands” section of the NT. This is a list of decorated Python functions (triggers) which are executed by the ROSIE server backend when the submitted job is run. The Python decorators allow the protocol writer to specify which of the input fields are passed to the trigger functions.

These trigger functions are then responsible for setting up the input files for the runs (typically by using Python string formatting functions on a template string that is included in the one Python file), and then launching the execution of the appropriate backend job. These backend jobs can be arbitrary programs, but most typically are Rosetta command‐line programs, RosettaScripts extensible markup language (XML) runs, or PyRosetta scripts. As ROSIE can interface with several cluster backends, the actual launching of the backend job is done indirectly, through an hpc_driver object. This object is set up by the ROSIE server prior to trigger function execution, based on the high‐performance computing (HPC) cluster in use at the time.

The trigger function is also responsible for output validation, checking to ensure that the backend run completed successfully and raising a Python exception if not. As a final step, the trigger function specifies the filenames for any produced structures and any output report files, which the ROSIE server architecture will then store in its database.

Presentation of results

The formatting of the results page (Fig. 2) is specified by the “output” section of the NT. As with the input section, we have created different output widgets (Table 2), which the ROSIE framework will assemble into a results page. Standard widgets are available to display the input parameters (including a structural rendering of any input protein, nucleic acid, or small molecule structures), as well as renderings of output structures, graphs of various scoring parameters, and tables of scoring and structural evaluation results.

Figure 2.

A ROSIE result page, showing output elements. A: The JobHeader widget provides details about the protocol run. B: The TopModels widget shows the selected result structures. Each structure can be downloaded by clicking on it. C: The ScorePlot widget displays a plot of two selected scores. Additional information for each point can be obtained by hovering over it. D: The ScoreTable widget. The results can be sorted by each column, and any particular structure can be downloaded by clicking its name.

Table 2.

Output Widgets

Output widget	Description
JobHeader	An overview of the inputs and running statistics
TopModels	Display and permit downloading the structures of the best results of the run
ScoreTable	Display a Rosetta scorefile in sortable tabular form
ScorePlot	Display a scatter plot of data from a Rosetta scorefile
Plot	Produce a scatter plot of arbitrary data
File	Display the text contents of an output file

In addition to the customizable rendering of output results, each results page contains links which allow the download of all produced results. Logging information is also available under the full output link, allowing users of failed runs to debug why their runs may have failed.

Documentation

As the intent of the ROSIE server is to make Rosetta protocols accessible to people with limited experience in computational biology, extensive documentation is needed to explain the usage and to describe how the adjustable parameters will affect the results. For this purpose, a “documentation” slot is provided in the NT protocol specification, which allows the protocol writer to provide an html‐formatted string which will be included on the documentation page for the protocol. Additionally, there are “citations” and “developed by” slots provided, which are included not only on the documentation page, but also on other pages of the ROSIE server. This information allows users to find the relevant papers describing the underlying protocol and the contact information for the protocol maintainer, respectively.

Protocols available through ROSIE

Brief summaries of the currently available protocols are given in Table 3. For more extensive discussion, as well as details of their operation, we refer the reader to the documentation on the ROSIE website (http://rosie.rosettacommons.org/documentation) and the cited papers.

Table 3.

Protocols Available Through ROSIE

Application	Developer	API	Introduced	Jobsa	References
Docking2	Gray at JHU	Meta	January 2012b	17,054b	50 and 51
Symmetric docking	André at Lund	Meta	August 2013	1081	52
RNA redesign	Das at Stanford	Meta	October 2013	76c	36
Ligand docking	Meiler at Vanderbilt	Meta	January 2014	3722	53 and 54
pK a	Gray at JHU	Meta	January 2014	1078	55
Peptiderive	Furman at HUJ	Meta	May 2015	2057	56 and 57
Make exemplar	Karanicolas at FHCC	Meta	September 2015	167	58
Snug dock	Gray at JHU	Meta	May 2016	363	51 and 59
Tox dock	Bonneau at NYU	Meta	May 2016	50
Lipid accessibility	Bonneau at NYU	Meta	August 2016	141	60
FARFAR	Das at Stanford	Original	February 2012	1706	36
ERRASER	Das at Stanford	Original	October 2012	232	37
Beta peptide design	Das at Stanford	Original	November 2012	19	38
Supercharge	Kuhlman at UNC	Original	November 2012	1013	43
Antibody	Gray at JHU	Original	December 2012	5133	44 and 45
NCBB design	Bonneau at NYU	Original	December 2012	43	46
Sequence tolerance	Kortemme at UCSF	Original	January 2013	741	47 and 48
VIP	Havranek at WUSTL	Original	March 2013	412	49

^aAs of September 2017.

^bIncludes jobs run with the original API.

^cRNA Redesign runs on a separate backend, and not all jobs may be adequately counted.

Protocols using the original framework

In addition to the new simplified framework, ROSIE still supports the original protocol specification framework. All eight of these protocols were also mentioned in the original ROSIE paper.35

Fragment assembly of RNA with full atom refinement—De novo RNA structure prediction

The Fragment Assembly of RNA with Full Atom Refinement (FARFAR) application models RNA structure de novo by combining short (1–3 nucleotide) fragments from existing RNA crystal structures.36 These fragment assembly models are then further refined with a full‐atom relaxation, resulting in predicted structures for RNA molecules.

Enumerative Real‐space Refinement ASsisted by Electron‐density under Rosetta

The Enumerative Real‐space Refinement ASsisted by Electron‐density under Rosetta (ERRASER) application is an RNA structure refinement protocol which uses electron density information to inform and guide the refinement.37

Beta peptide design

Beta peptides contain noncanonical backbones, with each residue containing an extra backbone carbon. The ROSIE Beta peptide design application takes such a backbone structure and predicts which sidechains (from the standard 20) would best support that backbone structure.38

Supercharge

Increasing the net charge on the surface of a protein can prevent aggregation,39, 40 increase expression and protein lifetime, alter cell entry,41 and affect kidney filtration.42 The ROSIE Supercharge application takes a protein structure and attempts either to maximize the surface charge (positive or negative, as specified), or to obtain a specific net charge, all while attempting to maintain the protein stability.43

Antibody

Antibody structure prediction is aided by the consideration of antibody‐specific structural features, which can be reliably predicted from their sequence. The ROSIE Antibody application uses this domain specific knowledge to model the predicted structure of an antibody given its primary sequence.44, 45 Due to the increased complexity, modeling the challenging HCDR3 loop is provided as a separate option.

Noncanonical backbones design

Noncanonical backbones (NCBB) can be more thermodynamically stable than standard alpha amino acids, and they are more resistant to native peptidases. The NCBB Design application redesigns existing peptide‐protein complexes by replacing the peptide's backbone residues with oligooxopiperazines, hydrogen bond surrogates and peptoids, while maintaining peptide–protein binding.46

Sequence tolerance

The Sequence Tolerance application examines a defined set of positions in a given protein–protein interface, predicting which mutations may be tolerated, and which may destabilize either the monomers or the protein–protein interaction.47, 48

VIP—Core redesign to eliminate voids

Voids in the hydrophobic core of a protein are correlated with reduced stability. The ROSIE Void Identification and Packing (VIP) application can examine the structure of a protein, locate voids in the core, and suggest mutations that could be made to improve core packing without destabilizing the protein.49

Protocols using the new meta API

The simplified meta API framework for protocol specification has allowed a number of additional Rosetta protocols to be exposed through ROSIE.

Docking2

The ROSIE Docking2 application is a rewrite of the previous protein‐protein docking protocol to use the new meta API. This application does a local docking search of a protein–protein interface, given a close starting conformation.50, 51

Symmetric docking

Assembly of a monomer into a symmetric oligomer is assisted by knowledge of that symmetry. The Symmetric Docking application uses knowledge of the desired symmetry to convert a structure of a monomer into a symmetric oligomer.52

RNA redesign

Given a three dimensional (3D) structure of a folded RNA, the RNA Redesign application will attempt to find an RNA sequence (A/U/C/G) which best stabilizes that particular backbone conformation.36

Ligand docking

The ROSIE Ligand Docking application allows users with a given small molecule to predict the binding conformation of that small molecule to a designated pocket on a 3D structure of a protein.53, 54

pK_a

The pK_a of charged amino acids in a protein can be substantially perturbed due to their surrounding environment and the charge state of surrounding residues. The ROSIE pK_a application predicts the pK_a of various residues in the protein based on their three‐dimensional context.55

Peptiderive

While many protein–protein interfaces are large, it has been found that much of the energy of interaction is localized to specific regions in the interface. The Peptiderive application examines a protein‐protein interface and attempts to locate the short peptide sequences which contribute the most to the interaction energy.56, 57 These peptides can then potentially be used as inhibitors of the protein–protein interaction.

Make Exemplar—Map small molecule binding pockets

Evaluating potential small molecule binders (such as in high throughput screening) is assisted by having a map of the “ideal” configuration of a ligand binding pocket. The Make Exemplar application creates such a map from the 3D structure of the protein, by placing atoms at the appropriate locations for hydrogen bond donors, hydrogen bond acceptors, and locations of hydrophobic atoms.58

Snug dock—Antibody/antigen docking

Standard protein–protein docking techniques do not necessarily sample all the relevant degrees of freedom needed for antibody/antigen docking. In particular, the flexibility of the antibody loops and the heavy/light chain interface are typically neglected in typical protein‐protein docking techniques. The Snug Dock application is tailored toward antibody‐antigen docking, with explicit additional sampling of the relevant internal degrees of freedom of the antibody.51, 59

Tox dock

Disulfide‐cyclized peptides are one major class of ion channel inhibitors. While these peptides are found natively as neurotoxins, their inhibitory effects may have therapeutic uses. The Tox Dock application docks these cyclized peptides into structures and homology models of ion channels.

Lipid accessibility

When examining membrane proteins, it is useful to know where the lipid bilayer contacts the protein. The mp_lipid_acc application examines structures of membrane proteins, and encodes the lipid accessibility of each atom in the B‐factor column of a Protein Data Bank (PDB) file.60 This annotated PDB can then be viewed in standard molecular viewers.

Server usage to date

From March 2013 (when the statistics in the previous ROSIE paper were gathered) to the time of writing (September 2017), over 4000 new users have registered with ROSIE. Along with an unknown number of anonymous users, they have submitted over 31,000 different jobs to the server. Through that time, the growth in the number of registered users as well as the number of new jobs has been approximately linear, adding approximately 80 new registered users per month, and serving approximately 875 new jobs per month. The computational demand in the same time period has been over 3.5 million CPU hours, or the equivalent of just under 100 CPUs in continuous use for the past 4 years. Much of this computational power was supplied on the Stampede cluster at the Texas Advanced Computing Center, through a grant from the Extreme Science and Engineering Discovery Environment (XSEDE).

Discussion

We have improved the method by which ROSIE server protocols are specified, which has greatly simplified the method by which new protocols are implemented. As such, the number of protocols freely available through the ROSIE website at http://rosie.rosettacommons.org has more than doubled since the last paper describing it.

Our long‐term goal continues to be to provide free web versions of all core Rosetta protocols. While there are 18 protocols currently on the ROSIE web server, additional protocols are not yet available through the server. The reduced complexity of the meta API described in this paper means that compatible protocols can be converted to run on the ROSIE server in a few weeks of work by a knowledgeable Rosetta developer. We plan to continue to add additional protocols to ROSIE, and encourage users interested in protocols not yet available on ROSIE to contact the ROSIE help forum at http://www.rosettacommons.org/forums/rosie/rosie-general to help guide which protocols get exposed as a web server.

Materials and Methods

ROSIE server infrastructure and meta‐API

ROSIE is implemented in the TurboGears web server framework, using a PostgresSQL database. The server is freely available to the public at http://rosie.rosettacommons.org.

Protocol for creation of new ROSIE applications

The following is a summary of the steps required for a developer to create a new ROSIE server with the new meta protocols specification format. ROSIE development tools and source code are available to registered developers through the RosettaCommons.

Install a local ROSIE test server

To facilitate rapid testing of the protocol, the ROSIE server environment is made available within a VirtualBox (http://www.virtualbox.org) virtual machine (VM). This VM can be downloaded, with the appropriate user name and password, from http://graylab.jhu.edu/ROSIE

All the software needed to run a ROSIE server locally is provided, including Rosetta (under ∼/rosetta/) and the ROSIE server software itself (under ∼/rosie/). As these may be out of date, you may wish to update one or both before continuing development, by using standard git revision control commands. (Note that any “push” of changes should be to a personal GitHub fork of the ROSIE repository, rather than the main ROSIE repository.)

Create a python script with your meta protocols

Your new meta protocol will live in a single Python script file in the rosie.front/rosie/meta/. (The other applications in this directory can be used as a guide when formatting and structuring your protocol.) The main specification of the protocol is the NT object, which contains entries for name, display name, input, input validator, commands, output, developed_by, citations, and documentation. Name, display name, developed_by, citations, and documentation entries are strings which provide textual information about the protocol for various locations in the server.

The input_ entry contains a Python list of input widget objects, and controls how the submission form is constructed. A list of currently available input widgets is given in Table 1. Each widget will be placed one after the other on the submission page. As the server is accepting potentially untrusted data over the internet, each widget accepts input validation parameters to raise an error if nonsensical or potentially malicious entries are given. In addition, the input_validator entry accepts a Python function which will be passed all the input values at the time of job submission to identify problematic interdependencies between entries.

The commands entry contains a list of triggers which will be run in order by the ROSIE backend. These triggers are specified using specially decorated Python functions which will be passed the values from the input widgets. These functions can execute arbitrary Python code to set up input files for external Rosetta runs, which are launched using a specialized HPC driver object to potentially run on a remote machine. To avoid resource starvation for other users, settings should be limited such that a single ROSIE job never takes more than 2000 CPU hours, with the average run preferably staying below 500 CPU hours. The trigger functions are also responsible for postprocessing the runs and passing back the processed results through annotated parameters. In this way the results of one trigger command can be used as input for the next.

The output entry controls the display of the results page for finished (and in progress) runs. This is a Python list of output widget objects, which will be placed one after the other on the results page. A list of currently available output widgets is given in Table 2.

Enable your new protocol in the ROSIE test environment

1. To enable your protocols on the website, import your protocol's Python module rosie.front/rosie/meta/__init__.py and add it to the list of protocols in that file.

2. Add a 1024 × 1024 sized image to rosie.front/rosie/public/images/<protocol name>_icon.png

3. To enable running your protocol on the local backend, add your protocol to rosie.back/rosie/rosie‐daemon.ini.template (and rosie‐daemon.ini, if present)

4. Go to rosie.front/. Run “source ∼/prefix/TurboGears‐2.2/bin/activate” then “python update_protocol_schema.py” to update the database

Test your new protocol server locally

1. In one terminal window, run the ./run‐rosie‐server.sh script in ∼/rosie/ to launch the webserver

2. In another terminal, run the ./run_rosie‐daemon.sh script in ∼/rosie/rosie.back/ to launch the ROSIE backend.

3. Open “localhost:8080” in your web browser to visit the local version of your web server

4. Test your new protocol in your browser to make sure it runs appropriately, updating your meta protocol file as needed.

5. When finished, push the results to your personal fork of the ROSIE GitHub repository, and inform the ROSIE system administrators for code review and integration into the central server.

Supporting information

Supporting Information