Documentation for UBQ_E2_thioester application

Author:

Steven Lewis smlewi@gmail.com

Metadata

Last edited 4/5/11. Code by Steven Lewis. Corresponding PI Brian Kuhlman bkuhlman@email.unc.edu.

Code and Demo

The code is at mini/src/apps/public/scenarios/UBQ_E2_thioester/; there's an integration test+demo at mini/test/integration/tests/UBQ_E2_thioester/. Note that the integration test is vastly under-cycled relative to getting it to do anything useful: the number of cycles it demonstrates should be sufficient to show some remodeling but not enough to get anywhere useful. To run that demo, go to that directory and run [path to executeable] -database [path to database] (at-symbol)options

references

• Saha A, Kleiger G, Lewis S, Kuhlman B, Deshaies RJ. Essential role for ubiquitin-ubiquitin-conjugating enzyme interaction in ubiquitin discharge from Cdc34 to substrate. Molecular Cell. In press.

You may want to look at the online supplemental info for that paper for a different presentation of how the code works.

Purpose

This code was written for a relatively singular application: modeling the thioester-linked state of an E2 enzyme charged with ubiquitin. It serves no other purpose. We had hypotheses about what this state might look like and used this code to generate models to examine those hypotheses and generate testable mutations. It is included in the release because it was published, not because it is expected to serve other purposes.

Algorithm

There are two important novel chunks of code associated with this algorithm.

The thioester-linked structure contains an E2 enzyme (treated as a rigid body) and a ubiquitin molecule (treated mostly rigidly). The C-terminus of ubiquitin (glycine) is chemically linked to a cysteine of the E2, resulting in a thioester bond between the proteins. It is this bond that this protocol remodels.

The remodeling algorithm is straightforward. It uses Rosetta's standard Metropolis/Monte Carlo random sampling tools. A series of possible Pose modifications are chosen from on each Monte Carlo cycle. These include modification of all torsions close to the thioester, including chi1 and chi2 of the cysteine, the thioester bond, and the effective psi and phi angles of ubiquitin's terminal glycine. These are treated directly by TorsionDOFMover instead of more familiar sidechain/backbone movers because the extra chemical bond changes the torsional preferences at these bonds, meaning that the Ramachandran and Dunbrack libraries do not apply. TorsionDOFMover internally checks against a molecular-mechanics bond torsion term (although this term is not in the broader scorefunction). Other possible Monte Carlo moves include standard Small/Shear moves on the two penultimate ubiquitin residues. After a random move, the Pose runs through Rotamer Trials (to quickly pack sidechains) and a minimization step before the Metropolis criterion is applied. Some fraction of MC cycles instead perform a full repack of the UBQ/E2 interface.

The thioester-building code first replaces the E2's cysteine with a CYX residue type, which has an open residue connection on its sulfur atom (and no hydrogen there). The UBQ glycine is then appended to this with a chemical bond, removing its terminus type. The remainder of ubiquitin is the prepended before the final residue, resulting in a normal residue ordering but a reversed atom-tree folding order (Ubiquitin folds from its C-terminus, rather than its N-terminus).

The protocol also includes embedded machinery for generating constraints which are based on experimental data from Saha, Kleiger, and Deshaies; and on PDB 1FXT which is also a model of a thioester-linked E2/UBQ complex. At the end of the protocol, there is filtering machinery to automatically reject models with no signficiant interface.

Limitations

The code is full of hardcoded assumptions that you are using our E2 of interest (CDC34 from PDB 2OB4) and ubiquitin (from 1UBQ, but other structures ought to work). If you really want to model a different E2 with ubiquitin, you'll need to write your own constraints section (or tear it out and replace it with a constraint file). If you want to do your own thioester modeling (which seems much more likely), start by using this protocol as a guide to setting up thioesters.

Input Files

See test/integration/tests/UBQ_E2_thioester/ for example usage. Basically all you need is an input structure.

• You will NOT be using standard job distributor inputs (-s/-l PDBs or silent files.). Use -UBQpdb and -E2pdb to pass in those structures.
• Ensure that the code has the correct path to the CYX residue type. It will be in your rosetta database; the path is in the integration test/demo. %(database)s/chemical/residue_type_sets/fa_standard/residue_types/sidechain_conjugation/CYX.params is its current location.

Tips

• The filters are good enough that you will need to generate only a few hundred models to get the results we saw in the paper. (Many more will be rejected by the filters; I am counting completed models here).
• The code has an unsupported mode allowing for KIC loop modeling. This was intended to be used with the E2 loop absent in PDB 2OB4. The loop was too long for KIC to solve effectively so we took a different path; the code is still present but senescent if you don't pass a loops file.

Options

UBQ_E2_thioester supports three types of options: general minirosetta options (packing, etc.), generic protocol options like "how many cycles" borrowed from the AnchoredDesign application, and UBQ_E2_thioester specific options.

UBQ_E2_thioester options

• UBQpdb - File - input UBQ PDB, we used 1UBQ.
• E2pdb - File - input E2 PDB; we used a trimmed version of 2OB4.
• E2_residue - Integer - Which E2 residue is the active cysteine? 85 is default; correct for 2OB4.
• SASAfilter - Real - minimum SASA filter value. Default 1000 used for production.
• scorefilter - Real - filter value for maximum total score. Default 10; 0 used for production.
• constraintweight - Real - weight on the constraint term in the scorefunction. Default 50 used for production.

AnchoredDesign options (borrowed for simplicity, not tied to AnchoredDesign in any other way); all are in the AnchoredDesign namespace

• AnchoredDesign::refine_temp - real - Monte Carlo temperature for refine phase (0.8 used for production)
• AnchoredDesign::refine_cycles - unsigned integer - number of refine phase cycles (20000 used for production)
• AnchoredDesign::refine_repack_cycles - unsigned integer - Perform a repack/minimize every N cycles of refine mode (100 used for production)

General options: All packing namespace options loaded by the PackerTask are respected. jd2 namespace options are respected, although input modes are not. Anything very low-level, like the database paths, is respected.

• run::min_type - string - Minimization overview and concepts - minimizer type. dfpmin_armijo_nonmonotone used for production.
• nblist_autoupdate - boolean - I'm told this makes minimization faster
• nstruct - integer - number of structures to generate
• packing:repack_only - boolean - because you don't want to design, you should pass this
• generic_job_name - file - this tags the output with a particular name, useful because since there's no normal job distributor input it give strange names to the outputs.

Post Processing

Pick the best models by total score and look at the satisfaction of your experimentally-derived constraints to decide which you think is most plausible. We used the models to successfully predict a mutation to rescue a defect caused by UBQ I44A.

Changes since last release

Rosetta 3.3 is the first release.