Rosetta 3.2 Release Manual

Documentation for FloppyTail application

Author:
Steven Lewis smlewi@gmail.com

Metadata

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

Code and Demo

The code is at mini/src/apps/public/scenarios/FloppyTail/; there's an integration test+demo at mini/test/integration/tests/FloppyTail/. 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

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. The system in question was a protein with a long (dozens of residues) flexible tail, which was not seen in crystal structures. Biochemical evidence suggested a particular binding site for the tail on a known binding partner (the two binding partners also had a known binding interface separate from this tail). The code was intended to model the reach of the long flexible tail and determine whether the hypothesized binding site was plausible.

The protocol is more useful for testing hypotheses about possible conformations, and exploring accessible conformation space, than for finding "the one true binding mode". If your tail is truly that flexible it might not have a "one true binding mode."

Algorithm

The algorithm is fairly simple: small/shear/fragment moves in centroid mode to collapse the tail into some sort of folded conformation from an initially straight-out-into-space extended conformation, and small/shear moves with repacking to refine its position. This is conceptually similar to how abinitio folding works, although it is not refined for that purpose (and does not contain temperature scheduling, etc).

The code is compatible with constraints during the centroid phase (passed in via commandline). Early modeling proceeded using constraints and some small hacks to help guide models to the hypothesized tail-binding site. Ultimately this was not necessary for the original system, but the code retains the ability to use constraints, etc. Your mileage may vary.

Limitations

This code can model internally flexible regions between domains, although that is not its intended purpose. It may not do a good job of detecting appropriate interfaces for repacking in this latter case.

This code is NOT intended to do "half-abinitio" where you know half a structure and want to fold the other half. Although it is modeled on abinitio, it is only tested on a truly floppy tail, and I have no idea if it is able to fold compact structures. It is resolutely not supported for that purpose.

Input Files

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

Tips

This code was intended for a single purpose, but it may work if you have a similarly flexible tail. It can also model internal flexible regions between domains.

Options

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

FloppyTail options

AnchoredDesign options (borrowed for simplicity, not tied to AnchoredDesign in any other way); all are in the AnchoredDesign namespace General options: All packing namespace options loaded by the PackerTask are respected. jd2 namespace options are respected. Anything very low-level, like the database paths, is respected.

Post Processing

You'll be using this application to model mostly unstructured regions. You should not put a lot of stock in any individual model. This is not the sort of application where you'll run it 10 times and then take the best-scoring result as an accurate guess for the actual protein structure.

In general you should pick some metric predicted by the model (if you read the paper, you'll see that it was a distance between two residues later found to be chemically crosslinkable). You can then mine the model population to see what this metric looks like in the top-scoring fraction of models. The extra_analysis functionality will facilitate this. I suggest histograms.

Changes since last release

There was a major under-the-hood change which decreases runtime, scaling favorably for very long tails. For the publication case it decreases runtime 10-25%.

Generated on Wed Feb 16 16:04:25 2011 for Rosetta Projects by  doxygen 1.5.9

© Copyright Rosetta Commons Member Institutions. For more information, see http://www.rosettacommons.org.