You are here

Is it possible to do alanine scanning in Rosetta 3.2.1.?

22 posts / 0 new
Last post
Is it possible to do alanine scanning in Rosetta 3.2.1.?
#1

If possible, how do I do it.? Because I don't see any page in the manual that talks abt alanine scanning. Thanks.

Post Situation: 
Tue, 2011-04-12 02:36
monos_morpheus

I hacked together code for it once but it's never been released. You can make do with a shell script and the fixbb app. A pyrosetta script would be superb here if you know any python; it would not be difficult to do in C++ either.

There may be a RosettaScripts module for it - I've asked someone else to comment.

Tue, 2011-04-12 07:17
smlewis

Sarel Fleishman has sent along a RosettaScripts XML file that will do it (remaining text his):

Yes, the example on the RosettaScripts wiki recapitulates Tanja[ Kortemme]'s implementation (first it does docking local refine):

My current recommendation is to instead use score12:

Tue, 2011-04-12 07:47
smlewis

looks like the forum at the XML markup. It's attached as a text file. Note there are TWO scripts in it - pick one before you try running it.

Tue, 2011-04-12 07:49
smlewis

Where can we find "RosettaScripts wiki"? I am also very interested in the example XMLs mentioned.

Sun, 2013-05-05 23:32
jarod

https://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/

The "RosettaScripts" documentation is ported in a fixed format from an internal wiki.

Mon, 2013-05-06 10:21
smlewis

Then how do I use this XML file as a script, since I thought XML is more for webpages.?

Tue, 2011-04-12 08:08
monos_morpheus

The XML file is an input script for the rosetta_scripts application. See the documentation at http://www.rosettacommons.org/manuals/archive/rosetta3.2_user_guide/Rose...

Tue, 2011-04-12 09:09
rmoretti

XML means eXtensible Markup Language. We extended it to Rosetta. You are correct that the most common use is on the Internet.

The RosettaScripts documentation is here: http://www.rosettacommons.org/manuals/archive/rosetta3.2_user_guide/Rose...

Tue, 2011-04-12 09:10
smlewis

Also, can I safely say that using ala_scan.xml and sending to the Robetta server should give me approximately the same results.?

Wed, 2011-04-13 09:24
monos_morpheus

The top half of the file I posted "recapitulates Tanja's implementation (first it does docking local refine)", which is probably what Robetta does. (This is a guess.)

Thu, 2011-04-14 07:12
smlewis

Hello Everyone,

I am using the RosettaScript above to do alanine scanning of a set of protein complexes. I moved the proteins of interest to the top of their respective PDB files and they are docked against the rest of the protein complex (often multiple chains). However, I observed in the docking output file that the coordinates of the protein chain of interest does not change.
Is optimizing only one side of the interface the usual procedure for protein-protein docking? If not, is there a way to specify optimizing both sides of the interface before doing alascan?
Just for confirmation, this script recapitulates Kortemme et al.PNAS 2002 paper and not the Robetta server, correct? I ask because when I use Robetta for comparison, I noticed that the output PDB files are the same as the input aside from the extra hydrogens. If the output (.out file) is the final structure used in alascan, then there appears to be no docking done by the server.

Thanks

Wed, 2013-03-20 14:30
ericw

The script says "Yes, the example on the RosettaScripts wiki recapitulates Tanja's implementation (first it does docking local refine):"

I interpret this to mean that the alanine scanning is a reimplementation of Tanja Kortemme's 2002 implementation - it is certainly not identical but it is the same in spirit. The docking is added ahead of time in this script, but not part of the original implementation. So, Robetta doesn't move the proteins, nor did Tanja...nor will you if you remove the docking mover.

I don't understand the rest of your question; you say "[the chains of interest] are docked", but also "the coordinates of the protein chain of interest does not change" - those seem to be opposites?

Wed, 2013-03-20 18:05
smlewis

Thank you for your reply.

The chain of interest does not get local refinement, so I guess I should say that I'm actually docking the rest of the protein complex to that chain. I apologize for the confusion. However, it is only a frame of reference and my interest is in the interface between the chain of interest and the rest of the complex (ie. to analyze the interface of chain AB and C, I move C to the top of the PDB file. It might make slightly more sense conceptually to dock C to AB, since my chain of interest is often a smaller protein relative to the complex, but I don't want to change the default jump setting for both docking and alascan, which adds to the complexity, since I'm processing large batches of complexes).

Since the original and Robetta implementation of alanine scanning does not include docking, maybe I can leave docking out.
I am under the impression that even the relatively high-resolution crystal structures I am using should first be optimized/relaxed to fit the Rosetta energy function. If so, in your opinion, is this docking procedure (which seems to only optimize one side of the interface) a good fit for this job? Or would you recommend another RosettaScript mover for the job?

Thu, 2013-03-21 16:15
ericw

I'm still not clear on what "optimize one side" means - if you mean only one side moves as a rigid body, that's normal - docking does not require both sides to move relative to the origin/frame of reference, only that one side moves relative to the other. If you mean only one side has rotamers changing, that's a bug and we can fix it. I don't think either side should see backbone movement - certainly not from docking; maybe the ddg filter does it.

For the purpose of alanine scanning, you are mostly making holes, so I think you can get away with just side chain optimization - this implies that the only pre-optimization you need to do is side chain, via something like "fixbb -database $db -ex1 -ex2 -ex_cutoff 0 -use_input_sc -ndruns 10 -nstruct 1 -packing:repack_only -s input.pdb", or by adding a similar packing mover to your script. Docking optimization is only necessary if you are checking if introduced clashes are "shallow" and recoverable. Full backbone relaxation isn't really necessary if you already have high-res crystal structures you trust. Disclaimer: I haven't done any alanine scanning recently..."state of the art" is a mushy term and varies from person to person, but it's worth carefully reading whichever paper you're trying to reproduce.

Fri, 2013-03-22 07:42
smlewis

This makes much more sense now. I didn't know what I was looking for and wasn't thorough enough in checking the output structure. There are very few but indeed I see changes in rotamers in a few residues in the target chain. The rest of the complex undergoes rigid body changes. This RosettaScript is exactly what I needed.

To help understand the protocol, could you clarify the point about introducing clashes? Since docking is the first step, do you mean checking clashes in the original PDB structure? Or do you mean that the rotameric changes are made before rigid body moves during docking?
I used this command:
rosetta_scripts.linuxgccrelease -s 1FV1.pdb -use_input_sc -nstruct 1 -jd2:ntrials 1 -database ~/rosetta_database/ -ex1 -ex2 -parser:view

Furthermore, since the docking mover is doing what I need it to, I probably shouldn't use the fixbb repacking you suggested. Or, are you suggesting that I could prep all my crystal structures using fixbb repacking and leave out the docking step since I don't really need changes to the backbone?

Thank you

Fri, 2013-03-22 17:17
ericw

Clashes: If you are doing alanine scanning, the only possible mutation that can make a clash is G->A, because everything else is bigger than A. Anything else to A will leave a hole.

Let's say you were doing methionine scanning instead - that will introduce clashes if the methionine is bigger or differently shaped than whatever it replaces. Some of those clashes are shallow, in that a small docking rearrangement will repair the clash and show that the methionine mutation is nearly neutral. Some are not shallow, and Rosetta won't be able to re-dock to a similar/good solution. So, if you are making small->large mutations, you MUST re-dock after mutation.

This protocol is doing docking before mutation. That's a good idea if you have reason not to trust the input, but if it's high-res crystal structures, it is unlikely to change the results. Rosetta often disagrees with crystal structures, even high-res ones, on side-chain details, especially when that particular sidechain didn't have great density. However, a large rigid-body movement by Rosetta is almost certain to be wrong (that would mean *all the density* was wrong), so there's no real point in letting Rosetta dock ahead of time.

If you are docking after, you do need to dock before, to maintain symmetry in degrees of freedom - you want to be able to separate any drift from the correct docked structure due to your mutation vs. drift due to Rosetta's scorefunction not liking the crystal perfectly.

For the same reason, since you repack after mutation, you must repack before mutation, to ensure that rotameric and energy changes are due to the mutation and not due to vagaries of the crystal structure.

I think you should pack before, and not dock at all. If you have the time, try pack+dock before, and dock after, and see how the results vary.

Fri, 2013-03-22 19:34
smlewis

Thank you very much.
This is exactly what I needed because I won't be analyzing any G->A mutations. I'll keep in mind the idea of docking before and after the next time I do this but I don't have enough time for that at the moment.
I end up with two methods. 1) Would you please tell me if the following script and command will do the same job as the fixbb repacking you suggested? The resulting structure looks as expected but I'm still new to RosettaScript.
rosetta_scripts.linuxgccrelease -s 2PJY.pdb -use_input_sc -nstruct 1 -jd2:ntrials 10 -database /rosetta_database/ -ex1 -ex2 -parser:protocol ala_scan.xml -parser:view > out.log

2) On the other hand, I can run fixbb repack to prep the structure. I seem to be able to run RosettaScript with Docking removed and use mover=null to do alascan without any other changes to the structure.

Sat, 2013-03-23 21:57
ericw

You should do option 2. You want all alanine scans to start from the same structure...repacking each time before the alanine mutation is A) wasteful of computer time, and B) will introduce some noise into the experiment.

Sun, 2013-03-24 12:13
smlewis

I didn't know that script will cause repacking before each mutation, which is not what I intended. Thank you for clearing this up and your advice.

Sun, 2013-03-24 14:49
ericw

I got one more question. After testing with no mover, I noticed that increasing the interface_distance_cutoff above around 10 (eg 20) does not increase the number of residues with ddG reported. I'm wondering if there is something else limiting the residues that are mutated to alanine or are those residues omitted because ddg =0. I'm comparing ddg results with another program and some residues are just slightly out of range of the rosetta alascan.

Mon, 2013-03-25 23:39
ericw

I think your interpretation is correct. The scorefunction doesn't go out that far, so mutations will have no direct effect on the interface at that distance. It *might maybe* be able to induce a repacking dominoes effect, but I don't know that the repacking detector is wide enough (it's probably 10 not 20 angstroms anyway).

Tue, 2013-03-26 07:41
smlewis