Author: Steven Lewis (smlewi - at - gmail.com)
Code by Steven Lewis. Corresponding PI Brian Kuhlman (bkuhlman - at - email.unc.edu).
The code is at rosetta/main/source/src/apps/public/scenarios/FloppyTail/ ; there's an integration test+demo at rosetta/main/tests/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
You may want to look at the online supplemental info for that paper for a different presentation of how the code works.
This paper uses FloppyTail but is not related to development. Key idea: the paper authors were able to productively use FloppyTail without significant assistance from the code's author.
This paper uses FloppyTail to generate models consistent with NMR and SAXS data for interpretation of a structure of biological interest.
This paper uses an ensemble of FloppyTail-generated models to assess probability/energy of disordered tail to ordered core interactions and predictions are experimentally validated.
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."
(Note that this section may duplicate some of the above, or the demo – it was written to stand alone and included here for posterity)
FloppyTail is aimed at “constrained docking”. It can be used when you have one or more relatively rigid domains, with flexible linkers connecting them / at their ends. For some cases, like the original flexible tail, the question is “where might this tail be able to dock onto the rigid protein?” For some cases, like two domains with a linker between them, it might be “how should these two proteins dock, given that some conformations are impossible because the linker can’t stretch that far?”
Broadly speaking, FloppyTail comes into play for FLEXIBLE linkers. There are two problems with this. First, the Rosetta energy function is parameterized on and for well folded crystalline protein. It will only do so well with flexible linkers, because its view of physics doesn’t allow for unstructured soluble protein. Second, flexible linkers are flexible in time, but a static structure has no time domain, so looking at the top model by score is not very informative about the state of the linker region. So, using FloppyTail and interpreting its results requires some careful consideration of the value of the results.
If your goal is “I have two proteins that are connected and I want to know what it’s going to look like” – that’s an expensive problem and the success rate is marginal. (It’s equally expensive, with an equally marginal success rate, to just do global docking and then try to solve the loop, which is a valid alternative).
If you have NO experimental data about your problem, you can use FloppyTail to generate hypotheses. Look at your result ensemble and see what interactions recur frequently in the better models, then think about ways to test experimentally if those interactions are real (via crosslinking or mutagenesis, perhaps).
Perhaps you have an idea of a conformation that might exist and you want to check computationally before trying the experiment. In this case, try using constraints to force the conformation you’re interested in to see if the system can accommodate it. If you get out models that still don’t have the interaction you wanted, or can only achieve it with tortured geometries, that constitutes a negative result from FloppyTail.
If you have experimental data – great! Constraints are the way to go. Run the code with constraints, and you’ll get much higher model quality to feed into further hypotheses. Alternatively, use the constraints to filter unconstrained results, or just use them to judge if the model population is realistic. This lets you generate an “envelope” of the things the system might be doing consistent with your constraints, which can be used for further cycles of experiment as necessary.
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. UPDATE: The code is compatible with constraints in both phases.
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, disordered tail, and I have no idea if it is able to fold compact structures. It is resolutely not supported for that purpose.
If you want to perform standard ab initio folding of a terminal sequence, you can use the Topology Broker's RigidChunk environment. This can be used in RosettaScripts or using the minirosetta application.
See tests/integration/tests/FloppyTail/ for example usage. Basically all you need is an input structure.
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.
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.
For release 3.4, FloppyTail supports multiple flexible linkers. To use these, you have to write your own MoveMap file to tell FloppyTail what is flexible, and pass it in via the flag in:file:movemap. The formatting is described in the header to the function core::kinematics::MoveMap::init_from_file (probably at core/kinematics/MoveMap.hh). Briefly, do this:
RESIDUE 20 30 BBCHI
RESIDUE 54 67 BBCHIto define flexible regions running from residues 20 to 30 and 54 to 67. This is in internal Rosetta residue numbering (from 1), not PDB numbering.
To use this feature you must also NOT use the following flags, because the movemap handles these data, so the program is set up to ignore inputs from these flags if passing a movemap.
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.
For 3.2, 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%.
For 3.3, the publication flag was added for simplicity. The C_root flag was added to speed computation on non-c-terminal tails. Constraints work in fullatom mode. Full support for domain assembly (internal linkers) was added.
For 3.4, I added the ability to specify a custom MoveMap, which also allows for multiple rigid and flexible regions.
For 3.5, FloppyTail was refactored into a proper Mover in the protocols library; this should be invisible to end users.
Loop modeling applications
Structure prediction applications: A list of other applications to be used for structure prediction