Rosetta Scripts: Loop Modeling w. Selective Repacking

[Anonymous]

Hi!

Two questions:

1) I have recently started using Rosetta Scripts and would like to know if there is a way to model a loop while optimizing chi angles of only selected residues. I remember you had previously alluded to TaskAwareMinMover – is that the route – if so how ? I am using the following XML file:

2) Finally, assuming a protein that is “nres” residues long, is it possible to use Rosetta Scripts to remodel only the last five residues, i.e. “nres-4” – “nres”.

[Anonymous]

Aroop,

It will make everyone’s life easier if you attach the XML – the forum eats the brackets.

A) Broadly, probably not to your first question – I don’t think the internal loops machinery is that forgiving, and it insists on repacking the way it wants to, not the way you want it to – this would have to be changed in the C++.

No idea. Try it with the CCD-style closure methods and see if it works. CCD is perturbation + closure; if you don’t have a loop then it’s just perturbation, which is what you want! If you don’t need it to be in RosettaScripts, the FloppyTail application is written precisely for this purpose.

[Anonymous]

Thanks Steven. Will ensure that I attach the XML file next time. Did not realize that brackets are chewed up.

And thank you for reminding me of FloppyTail! Can FloppyTail be combined with symmetry?

[Anonymous]

Thanks Steven. That will be very helpful if there exists such a hack to accomplish the same.

[Anonymous]

Brian Weitzner confirms my opinion that there’s no good way to tell loop modeling to not pack things without editing the C++.

Why do you want to not pack certain residues? I can’t think of any situations where preventing packing is that good of an idea. You may be able to get away with strong dihedral constraints on the residues you want to not move; this can provide a huge energy bonus to staying in a particular rotamer, which will prevent the packer from moving it in a roundabout, inefficient fashion.

[Anonymous]

The loop that I am modeling is adjacent to residues required for binding. I want to preserve those neighbor residues in their bound state and find the lowest energy loop conformation given those states. Trust it makes sense. At the moment I am building the loop, copying over crystal bound rotamers and minimizing them for each decoy with a unique loop conformation.

Do let me know Ben Stranges comments on symmetric FloppyTail.

[Anonymous]

Dear Ben,

This is very helpful. Steven pointed out the Wiki sometimes gobbles up brackets and I think it did the same with a couple of the include statements. However, I figured it out and have included:
core/pose/symmetry/util.hh

along with the //what if symmetry lines.

This compiles fine, but then a couple of issues still remains:
1) Can I have the score12prime weights file ? I substituted it with the “score12”, but then after execution, the XML file loads file and after running for a while I am getting an error:
ERROR: !core::pose::symmetry::is_symmetric( pose )
ERROR:: Exit from: src/core/scoring/ScoreFunction.cc line: 577

2) I removed the line: OUTPUT scorefxn=s12p_symm from the XML file because it gave an error:
ERROR: OUTPUT is not known to the DataLoaderFactory. Was it registered via a DataLoaderRegistrator in one of the init.cc files (protocols/init/init.cc or protocols/init/init.cc)?
ERROR:: Exit from: src/protocols/jd2/parser/DataLoaderFactory.cc line: 76
Do I need the OUTPUT line and if I do how do I make that happen ?

3) Finally, my protein is 414 residues long and I am interested in moving the region between 401-404. I do not want to tweak the phi-psi-omega and chi angles of residues 405-414, but I want them to move like a lever in response to the flexible residues (401-404). Thus I have replaced all instances of:
%%flexstart%% with 401
%%flexend%% with 404
%%numres%% with 414
%%symmfile%% with the name of my sdef file

The main failure is point 1 which might be because of the missing score12prime weights file. I am new to RosettaScripts and this script certainly resolves a lot of the cobwebs. Thank you for sharing it.

Thank you once again for your help,
Aroop

[Anonymous]

Dear Ben,

Also I found from RosettaScripts documentation that this error is caused by:
scorefxn_ = new ScoreFunction( *data.get< ScoreFunction * >( “scorefxns”, sfxn_name ));
and should instead be replaced with:
scorefxn_ = data.get< ScoreFunction * >( “scorefxns”, sfxn_name )->clone();

Do you know if you replaced respective lines to accommodate this? If so can you share the diff (attach instead of copy).

Thanks once again,
Aroop

[Anonymous]

Thanks Steven,

I just found the weights, but thanks once again.

I am guessing that the only thing that I need is where the scorefxn_ changes need to happen to run the script. Can you please ping Ben for me or pm his email id ?

Aroop

[Anonymous]

Thank you Steven. I shall wait for Ben’s reply.

[Anonymous]

Dear Ben & Stven,

I finally have managed to make some headway with your script. The offending line is:
“Add mover_name=symm_min_final filter_name=score_filter”

If it is present, I get an error as outlined here:
http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#Issues_with_Symmetry_and_Rosetta_Scripts

(the only difference is that the line number is 577 in my case, but that I guess has to with when the version was released)

I am guessing that this has since been fixed and the current trunk works fine. Can you diff the current trunk src/core/scoring/ScoreFunction.cc with the 3.4 release version and check if there has been any relevant changes which I can incorporate into my version?

@Steven: Can you connect me to a Rosetta Developer who has been working on this for further clarity ?

Thank you,
Aroop

[Anonymous]

Dear Steven,

1) I traced that the error results from the following filter:
“ScoreType name=score_filter scorefxn=s12p_symm threshold=-1.0”
even though I have specified that the scorefxn is symmetric:
“s12p_symm weights=”score12prime” symmetric=1″

As mentioned here: http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#Issues_with_Symmetry_and_Rosetta_Scripts

“One RosettaScript-specific problem with parsable movers and symmetry has to do with how the scorefunction map is accessed in parse_my_tag. When getting a scorefunction off the data map, the following code WILL NOT WORK WITH SYMMETRY: “

However, I know that this particular line works for Ben, which leads me to believe that there must have been relevant changes to accommodate the same. Thus I wanted to get clarification from someone who is actively developing in this area.

2) I want to use atom pair constraints in Rosetta Scripts. To do this I have:
a) Introduced a weight in the scoring function:
“Reweight scoretype=atom_pair_constraint weight=2.0”
b) Setup a constraints mover:
“ConstraintSetMover name=cst_cen cst_file=”n191.cst””
and included the same in “PROTOCOLS”

I want to know if there should be any entries in APPLY_TO_POSE to tie the constraint to the pose? Also is there any way to see the constraints score in the output model/scorefile?

Thanks for your help,
Aroop

[Anonymous]

Dear Steven,

I modified the following file:
src/protocols/simple_filters/ScoreTypeFilter.cc

where I replaced the following line:
//scorefxn_ = new ScoreFunction( *(data.get< ScoreFunction * >( “scorefxns”, scorefxn_name )) );
with
scorefxn_ = data.get< ScoreFunction * >( “scorefxns”, scorefxn_name )->clone();

Now my XML script with ScoreType filter using a symmetric score function works fine.

However, I would still like some help with applying Atom Pair Constraints in the XML file (as discussed in my previous post).

Thank you,
Aroop

[Anonymous]

By using your cst_cen ConstraintSetMover in the protocols section, you’ll add the constraints to the pose starting at that point, with no need to use the APPLY_TO_POSE section.

To get the scores in the output model, you’ll need to use a scorefunction on the command line with the atom_pair_constraint weight set. (There’s now a way to set the output scorefunction from within the XML, but that’s not in the currently released version.) If all you’re interested is getting the value in the scorefile, one way is to set up a ScoreType filter with score_type=atom_pair_constraint and confidence=0, and then use that in the protocols section. (Any filter used in the protocols section will also be applied after the protocol ends, and the value for that filter will be reported in the scorefile. The confidence=0 will keep it from truncating the runs for “failing” the filter.)

[Anonymous]

Dear Rocco,

Thank you for the heads up. I will try the filter method with confidence=0. For the alternate command line option that you have mentioned. Will the following work:
Command line option: -score:weights trial

where in trial.wts file I have atom_pair_constraint = a non zero number

If I have such a setup then the RosettaScripts decoy will have the atom_pair_constraint in the scores following the ATOM entries ?

Thank you,
Aroop

[Anonymous]

Dear Steven & Rocco,

Thank you, it worked! The constraint value was evaluated and printed in the last line of each decoy.

I did not have to enter any special command line option, but simply in my XML file:
1) Set the atom_pair_constraint weight to 1.0
2) Set a dummy filter to evaulate the new scorefxn (with atm_pair_cst set to 1.0)
3) Set a ConstraintMover to read in the sets of atoms being evaluated
4) In PROTOCOLS, added the ConstraintMover along with the dummy filter

And presto, the last line of the decoy had the atom_pair_constraint evaluated and was preceded by the variable name of the dummy filter used. If you have multiple filters, I saw that each filter was printed at the end of the decoy file.

Thank you once again,
Aroop

[Anonymous]

Floppytail: No, but I think Ben Stranges either hacked it in or has a script that mimics it (FloppyTail is really simple internally). I’ve cc’ed him.

[akhmelin]

Hi Aroop,
What I have is a temporary hack consisting of modifying the code in BackboneMover.cc and using the attached script.

Below is what I added to BackboneMover.cc. Steven says it’s not a good permanent fix though…

git diff master..development
— a/rosetta_source/src/protocols/simple_moves/BackboneMover.cc
+++ b/rosetta_source/src/protocols/simple_moves/BackboneMover.cc
@@ -29,7 +29,8 @@
#include
#include
#include
–
+//symmetry
+#include
// Random number generator
#include
#include
@@ -173,6 +174,12 @@ void BackboneMover::apply( core::pose::Pose & pose )
// clear everything to start from clean
clear();

+ //what if symmetry?
+ if ( core::pose::symmetry::is_symmetric( pose ) ) {
+ core::pose::symmetry::make_symmetric_movemap( pose, *movemap_);
+ }
+
// currently secstruct is not implemented and returns ‘L’ for all residues
setup_list( pose );

[Anonymous]

> cat score12prime.wts
# Standard.wts + score12 patch weights, refit reference energies
# with optE for sequence profile recovery.
# Reference energies normalized so that they sum to one.
METHOD_WEIGHTS ref 0.149742 -0.000206398 -0.47402 -0.604935 1.15537 -0.310674 0.954298 0.396603 -0.442574 0.207128 -0.204523 -0.74518 -0.654485 -0.781173 -0.76836 -0.298617 -0.22266 0.325644 1.39013 0.928496
fa_atr 0.8
fa_rep 0.44
fa_intra_rep 0.004
fa_sol 0.65
pro_close 1
fa_pair 0.49
hbond_sr_bb 0.585
hbond_lr_bb 1.17
hbond_bb_sc 1.17
hbond_sc 1.1
dslf_ss_dst 0.5
dslf_cs_ang 2
dslf_ss_dih 5
dslf_ca_dih 5
rama 0.2
omega 0.5
fa_dun 0.56
p_aa_pp 0.32
ref 1

[Anonymous]

1) The !core::pose::symmetry::is_symmetric( pose ) has nothing to do with score12 versus score12 prime. It’s solely to do with symmetry. If you’re working with a symmetric pose, you need a symmetric score function (see http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/RosettaScripts_Documentation#Symmetric_Scorefunctions ).

I believe a symmetric scorefunction can handle non-symmetric poses, but in general you’ll want to match the symmetric/not-symmetric status of the pose and the scorefunction. (This is on the list of things to get fixed eventually.)

2) The OUTPUT line was added after the 3.4 release. What it does is cause the outputted structure to be scored with the given XML scorefunction, rather than the command line default. It’s not really needed. You can either ignore the scores in the output structures, or pass the desired weights file on the command line. (The command line loading should take care of symmetry, as long as you’re not symmetrizing the scorefunction during the XML itself.)

3) The %%whatever%% notation in the XML is for scriptvars ( http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/RosettaScripts_Documentation#Variable_Substitution ) which you can automatically substitute from the commandline, but manually changing them will work too.

[Anonymous]

He should have gotten an email automatically from the forum software. I can send him one to make sure.

[akhmelin]

Hi Aroop,
I don’t remember changing any of the score function handling. I’m using trunk Rosetta r53057 with the alternation to BackboneMover that I mentioned previously. I just compiled and ran with the attached options file (and the xml script I attached previously) and it worked without a hitch. If you are still having trouble could you say exactly where it’s failing? I can’t really troubleshoot it because it doesn’t replicate for me. Are you declaring that your score functions are symmetric?

[Anonymous]

1) I just noticed that there *was* a symmetry flag set in the XML. In that case it would be helpful to get more context as to where the error was occurring. Rosetta scripts typically prints out which mover/filter it is currently working on to the tracer. Which mover/filter was it working on just prior to the error? (You may need to rerun the program with the output going directly to the terminal in order to get a good reading of this – redirecting to log files sometimes cuts off the last bit of tracer output.)

[Anonymous]

The error you link to is going to be an error caused by an incorrect parser setup function in a Mover (probably a parse_my_tag), not an error in ScoreFunction. (You are correct that it is exposed by ScoreFunction).

I don’t see any changes to ScoreFunction.cc that are of any use.

I would guess you can compile in debug mode and run it in the debugger to catch the crash and backtrace to which Mover is trying to use a wrong ScoreFunction (so you know which one to change the parse_my_tag function of).

[Anonymous]

“If I have such a setup then the RosettaScripts decoy will have the atom_pair_constraint in the scores following the ATOM entries ?”

Assuming that the last scorefunction the Pose is scored with is the scorefunction built from your “trial” weights set, and that the constraints added by Rocco’s advice are still around, it will. For a setup this complex we’ll just have to try it to find out.

[Author]

Posts