You are here

CoupledMoves not altering backbone coordinates?

16 posts / 0 new
Last post
CoupledMoves not altering backbone coordinates?

HI All,

I'm beginning to play around with CoupledMoves for flexible backbone design and I am unable to get it to alter the protein backbone coniguration.

When I run the tutorial here ( it works. But when I try and apply that (or similar) command to another protein it will deisgn the sequence, but all the output pdbs have no coordinate changes. 

I have tried to simplify the comand line to the barest/most default possible, but I still cant get it to work. I suspect I'm doing something dumb, but can't figure out what exactly. Any guidance would be apprecaited. 

Thanks. -Andrew


Command and resfile below:


~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -nstruct 4 -coupled_moves::ntrials 20 -s 2ilk.pdb -resfile test.resfile






1 - 6 A ALLAAxc


Post Situation: 
Wed, 2021-01-20 11:38

I'm just beginning to play around with coupled moves, too. I have two ideas though: have you tried to alter your resfile and design other sites? It doesn't appear that 2ilk has residue 1-5 and res 6 is a partially modified residue. It might be that the resfile is using pose numbering and not pdb numbering in which case you're fine. The second idea is to increase your ntrials. I don't know if every move is accepted in the algorithm so maybe it's just that all the moves in the 20 trials are being rejected.

Adding '-coupled_moves:trajectory true' and '-coupled_moves:save_structures true' might help you debug.

Best of luck!

Tue, 2021-01-26 08:00

Hey David! How's it going? Thanks for the reply.

Yeah, I renumbered 2ilk starting from 1 and 1-6 is a loopy tail that should move around a lot. Also I've tried other proteins. But thanks for mentioning it because that is the type of mistake I make all too often.

The ntrials and trajectory suggestions are definitely good ones and may help me diagnose the problem. I'll give then a shot and report back.


Tue, 2021-01-26 10:44

Ok. So prompted by David, I tried another few experiments. The bottom line is that I still can't get CoupledMoves to do anyhting of significance. 

What I found:

1) the default ShortBackrubMover does indeed alter the backbone, but only by small fractions of an angstrom - like need to diff the pdbs to see the change. As before it does also design/alter the sequence, but acccepts a very lmiited number of mutations due (assumedly) to the non-changing backbone. 

2) the WKIC mover does nothing except repack the sidechains slightly - neither sequence or backbone changes. 


I changed the loop  to be designed from a terminal tail to an internal loop a) just to try on another region and b) becuase I wanted to also try the walking KIC mover (which needs an anchor point). I also tried many permutations on parameters such as -ntrials, -walking_perturber_magnitude and -kic_loop_size. Finally I output trajectories to see if any of the intermediate files evidenced backbone moves.

I know many rely on CoupledMoves as their goto for design, so I'm sure it is somehting I'm doing wrong. I'd just love ot find out what. Maybe others are having my same difficulties.

Thanks all for your continued input. 





Below are xamples of a few comands I tried. 

  506  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -nstruct 4 -coupled_moves::ntrials 100 -s 2ilk_WT_relaxed.pdb -resfile test.resfile &

  527  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::backbone_mover kic -coupled_moves::kic_perturber walking -coupled_moves::walking_perturber_magnitude 2.0 -coupled_moves::kic_loop_size 5 -coupled_moves::ntrials 200 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite &

  530  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::backbone_mover kic -coupled_moves::kic_perturber walking -coupled_moves::walking_perturber_magnitude 30.0 -coupled_moves::kic_loop_size 11 -coupled_moves::ntrials 200 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite &

  531  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::backbone_mover kic -coupled_moves::kic_perturber walking -coupled_moves::walking_perturber_magnitude 10.0 -coupled_moves::kic_loop_size 7 -coupled_moves::ntrials 200 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite &

  533  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::backbone_mover kic -coupled_moves::kic_perturber walking -coupled_moves::walking_perturber_magnitude 30.0 -coupled_moves::kic_loop_size 21 -coupled_moves::ntrials 200 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite &

  534  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::ntrials 200 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite &

  536  ~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -nstruct 4 -coupled_moves::ntrials 100 -s 2ilk_WT_relaxed.pdb -resfile test.resfile -overwrite -coupled_moves:trajectory true -coupled_moves:save_structures true -coupled_moves:trajectory_stride 1 &


Attached is my starting pdb, below is my resfile.



38 - 45 A ALLAAxc


File attachments: 
Wed, 2021-01-27 15:29


So I've also now tried CoupledMoves on a newer weekly rosetta release, on linux as well as macos and on both static and mpi compiled versions. And if I "PIKAA W" for all dozen positions in the loop it will dutifully add all tryptophans but still not alter the backbone more than a fraction of an angstrom and write out files with really terrible scores due to the clashes.

I've also found that if you include "-coupled_moves::initial_repack false" it won't alter the sequence, regardelss of what the resfie says - which doesn't seem correct either.

I’m at a loss for what else to try. Is there documentation other than this that I may have missed?

If anyone is willing to share a few input files and a command that worked for them, I'd be very grateful. Something basic would be great. Complicated would be fine too.  





Thu, 2021-02-04 11:27

I'm not having this issue when I run coupled_moves. I prepared my protein with the pareto-optimal relax protocol and then ran coupled_moves with commands from the docs. Plenty of mutations arise and my backbone movement approaches 0.5 angstroms at some residues (though much smaller in other sites).

Some thoughts:

  • Have you tried to run on the un-relaxed structure? Maybe relax put you in a very deep energy minimum?
  • Are you allowing neighboring residues to repack? Possibly both sequence neighbors and spatial neighbors need to be set to NATAA?
  • What happens when you set all sites to designable? ("ALLAAxc \n start" as your resfile)


In terms of docs, you might look at this recent paper but based on previous comments I think you might've already seen it: Loshbaugh, A. L., & Kortemme, T. (2020). Comparison of Rosetta flexible-backbone computational protein design methods on binding interactions. Proteins, 88(1), 206–226.

I also tagged a few people in the community to draw more attention to this post. Hopefully, they can guide you a bit further.

Thu, 2021-02-04 09:51

Hi David. Thanks for sticking with this. And I appreciate you drawing attention to my issue.

-I've tried a global NATAA at the beginning of the resfile. No differnece.

-Besides taking a lot longer to run, setting all to ALLAAxc makes no differnce.

-And yes I did see Amanda's paper and tried several of the commands in the supplementary materials to no avail. 


As I mentioned in my response to Amanda below, maybe my expectations of what CoupedMoves does are off. If I do the same design with relax, or backrub, or remodel, then the magnitide of change I expect to see in the designed loop wuld be very large. And if I were to design in a dozen tryptophans into an internal (or terminal) loop, it would not only show large backbone movelment, but would in all likelyhood significantly disrupt the overall structure. Is that not what I should expect form CoupledMoves? Or is this unalterably more of a relax with constrain to start coordinates kind of mover? 



Thu, 2021-02-04 12:00

have you tried increasing the mc_kt option to e.g. 1.4?

Thu, 2021-02-04 10:16

Hi Amanda. Thanks fo rresponding.

Yes. "-coupled_moves::mc_kt 1.4" and/or "-coupled_moves::boltzmann_kt 1.4" make no difference in the output. 

Thu, 2021-02-04 11:36

also consider pre-generating a backbone ensemble using the standalone backrub application, then using coupled moves to design with flexibility on the ensemble. have you tried running backrub w/ the equivalent options (mc_kt, ntrials) and seeing how the amount of backbone movement compares?

Thu, 2021-02-04 10:20

Adding the extra step of pre-generating with BR would kind of remove a lot of the speed/efficiency benefit, motivation for using CoupedMoves to begin with, no?

And changing mc_kt and ntirals doesn't significantly change the output. Higher ntrials perhaps catches me more on the extreme tails fo the distrobution, but all the changes are still very small. 

Add to that the odd behavior of "-coupled_moves::initial_repack false" causing it to ignore the resfile and not alter the sequence, and only the default backrub mover doing anything at all but repacking sidechains. 

Maybe my expectations are off, but when I replace a dozen residues in a loop with all tryptophans and they clash so badly that a  -400reu score turns positive and there is still no more than a fraction of an angstrom change in the backbone, that doesn't seem like things are working as they should.

Thu, 2021-02-04 11:48


I have been unable to resolve this inability to perform significant backbone sampling. It is a good assumption that it is something I am doing wrong, but so far my own efforts and others suggestions have been unable to identify what that is, or to get CoupledMoves to work as described.


To recap:

1) Coupled moves will not significantly alter the backbone configuration of a designed segment.

            a) The default shortbackrub mover will alter the backbone a small fraction of an angstrom, but far less than expected – even when mutating in a dozen TRPs that clash badly. 

            b) the WKIC mover will neither respect a resfile nor do anything but repack native sidechains. 

            c) Using the "-coupled_moves::initial_repack false" option results in no design nor backbone moves – similar to using WKIC.

            d) Trying different loops, PDBs and resfile combinations (NATRO, ALLAA, etc.) has no effect on output.

            e)  Altering parameters such as mc_kt and boltzmann_kt has had no effect on output.


My expectations are that CoupledMoves will behave similarly to FastDesign/Relax and sample backbone conformational space to a similar degree. So far I have been unable to make anything like that that happen. Please let me know if those expectations are incorrect. 


Next steps:

To help identify the extent of the issue, the next thing it would be very helpful to try is if someone could run the below (attached) pdb/command/resfile to confirm it does/does not work for everyone else. Alternatively, I’d be more than happy to run someone else’s pdb/command/resfile if you would kind enough to provide them. 



If anyone else is having similar issues with CoupledMoves, please comment here so we can get additional attention.

Thanks all!




~/Rosetta/rosetta_bin_mac_2020.08.61146_bundle/main/source/bin/coupled_moves.static.macosclangrelease -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -nstruct 4 -coupled_moves::ntrials 100 -s 2ilk_WT_relaxed.pdb -resfile test.resfile





38 - 45 A PIKAA W


File attachments: 
Mon, 2021-02-15 15:36

Hi Andrew, I'm starting to look into this more closely, apologies for the delay.

Here is an example of 10 structures i generated with the command below:

~/rosetta-main/source/bin/coupled_moves.default.linuxgccrelease -s input.pdb -ex1 -ex1 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -nstruct 100 -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -linmem_ig 10 -resfile resfile.resfile -coupled_moves:ntrials 11111 -coupled_moves:ligand_mode 1 -coupled_moves:number_ligands 2 -coupled_moves:mc_kt 2.4 -coupled_moves::backbone_mover backrub -in:file:extra_res_fa LIG.params

where resfile.resfile = NATAA start, then resn chain PIKAA WT for all positions


Trying your commands:


1 - 6 A ALLAAxc

~/rosetta-main/source/bin/coupled_moves.default.linuxgccrelease -s 2ilk_WT_relaxed_0.pdb -nstruct 1 -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -linmem_ig 10 -resfile resfile2 -coupled_moves:ntrials 100 -coupled_moves:mc_kt 2.4 -coupled_moves::backbone_mover backrub -out:suffix _resfile1-6ALAA

protocols.moves.TrialCounter:          RESIDUE trials=    100;  accepts= 0.7800;  energy_drop/trial=   0.03243

38 - 45 A ALLAAxc

 ~/rosetta-main/source/bin/coupled_moves.default.linuxgccrelease -s 2ilk_WT_relaxed_0.pdb -nstruct 1 -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -linmem_ig 10 -resfile resfile3 -coupled_moves:ntrials 100 -coupled_moves:mc_kt 2.4 -coupled_moves::backbone_mover backrub -out:suffix _resfile38-45ALLAA

protocols.moves.TrialCounter:          RESIDUE trials=    100;  accepts= 0.6600;  energy_drop/trial=   0.11827

Both of these ALLAAxc results look fairly normal to me. There is fine movement of the backbone visible when viewed in pymol compared to the input structure. There is no large pressure for the backbone to shift, given the ALLAA resfile the sampling and scoring will arrive at side chains that are a close fit to the input backbone.

Residues 1 and 6 / 38 and 45 are necessarily locked in place as the pivot residues of the backbone moving algorithm, whether it's backrub or kic the pivot at the ends of the region cannot move by definition. This seems like a reasonable amount of movement to me for a small segment restricted by pivots. There's really just not anywhere for it to go, given the pivot restrictions.

Keep in mind CoupledMoves is designed for fine movement, not large scale sampling. I've been running CoupledMoves and FastRelax side by side on my current protein target, and they produce similar looking ensembles when allowed to freely sample all backbone torsions (no sequence design). Apologies that I cannot share those results.


38 - 45 A PIKAA W

~/rosetta-main/source/bin/coupled_moves.default.linuxgccrelease -s 2ilk_WT_relaxed_0.pdb -nstruct 1 -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -linmem_ig 10 -resfile resfile.resfile -coupled_moves:ntrials 100 -coupled_moves:mc_kt 2.4 -coupled_moves::backbone_mover backrub

you're right it barely moves

however i noticed something looking at the scores in the pdb (to find quickly outliers i opened the score table in excel and conditionally colored by column)

label fa_atr fa_rep fa_sol fa_intra_rep fa_intra_sol_xover4 lk_ball_wtd mm_bend fa_elec pro_close hbond_sr_bb hbond_lr_bb hbond_bb_sc hbond_sc dslf_fa13 omega fa_dun p_aa_pp yhh_planarity ref rama_prepro total
weights 1 0.55 1 0.005 1 1 1 1 1.25 1 1 1 1 1.25 0.4 0.7 0.6 0.625 1 0.45 NA
pose -992.228 726.45 597.501 1.84431 32.007 -32.1249 168.15 -268.177 0.21675 -97.6763 -2.79313 -21.0189 -22.0049 -2.63587 26.9986 217.674 -14.3089 0 36.0322 8.94296 362.848


TRP_42 -14.2007 103.124 2.9324 0.01931 0.33331 0.19225 1.33995 -2.46375 0 -0.44349 0 -0.66079 0 0 -0.02394 2.17866 0.04785 0 2.26099 0.90812 95.5438
TRP_43 -15.2739 209.392 2.17884 0.0196 0.22975 -0.01989 0.279 -1.74019 0 0 0 -1.50256 0 0 0.11462 2.06084 -0.01054 0 2.26099 0.90733 198.896


MET_63    -11.6775    30.334    2.12164    0.01728    0.0937    -0.26015    0.42082    -1.43356    0    -0.9922    0    0    0    0    0.11431    1.32095    -0.09067    0    1.65735    -0.33522    21.2908            
PHE_66    -11.9287    24.1573    3.46897    0.02415    0.27019    -0.18508    0.46055    -3.12612    0    -0.814    -0.35256    0    0    0    0.11264    2.24592    -0.55891    0    1.21829    0.08674    15.0794
TYR_67    -13.7332    147.07    3.79944    0.02095    0.20622    -0.02228    0.77666    -2.51893    0    -0.50952    -0.70515    -0.67622    0    0    0.00455    2.79386    0.1257    0    0.58223    0.08226    137.297
VAL_119    -9.70332    31.1353    3.03632    0.01688    0.05277    -0.08661    0.32557    -2.37268    0    -0.93708    0    0    0    0    -0.05379    -0.00612    -0.356    0    2.64269    -0.15454    23.5394
PHE_123    -10.5312    36.8464    4.08767    0.02417    0.2689    -0.17964    0.53022    -2.08649    0    -0.85782    0    0    0    0    0.00706    1.93369    -0.47443    0    1.21829    -0.16242    30.6244
PHE_141    -13.3718    33.8069    2.3363    0.03048    0.31212    -0.17301    0.32103    -1.86453    0    -1.23092    0    0    0    0    -0.0172    3.75049    -0.17805    0    1.21829    -0.09808    24.842

the scores for the total pose, and for the residues i've pulled out, are yikes really bad.

the reason is because your resfile is set for NATRO for the non-mutated positions, but you've mutated a bunch of giant tryptophans that clash. since the score is so far off the charts bad, this isn't really a reasonable test case. keep in mind changing the temperature doesn't change the size of the move, just the likelihood of acceptance. for this PIKAA W example, the energies are so bad that any given move by this algorithm is unlikely to improve the energy, so it may be difficult for sampling to exit the plateau. there may be no rotamers for those TRP 42 and 43 that relieve the clash (rotamer sampling step), and the small-scale backbone moves (backbone sampling step) may not be enough to find the edge of the plateau.

to prevent this type of error, the documentation suggests: "Use -exclude_nonclashing_positions flag to autodetect all positions that clash with designable positions. Start with a NATAA default resfile that defines designable positions. The CoupledMoves protocol will keep as NATAA only positions that clash with designable positions, while all other positions will be switched to NATRO." This is an important lesson, you can sequence design a position but you must allow the shell around it to repack.

if you don't trust the automatic detection, you can also use the pymol "around" syntax with pymol commands like:

select around_5, byres((PDB and resi 5) around 5 and n. ca and PDB)
iterate(around_5 & n. ca), around_5resfile.add(resi)

print( "around_5resfile" )
for i in sorted(around_5resfile ):
    print(f'{i} A NATAA')
python end

third option for sanity you could relax the entire structure again after design and the scores would likely improve a lot.

changing the walking perturber magnitude does change the size of the move, so not sure what's up with that (i did not try that command here). i think maybe if you set the kic loop size larger than the number of residues designable, it may not be able to sample (don't quote me). try setting kic loop size to 3 and see if that allows backbone movement. i'm also not sure about how physically realistic it is to set the walking perturber magnitude high, this may make it so moves are almost always rejected. check the protocols.moves.TrialCounter line in the logs to see if moves are accepted. should be around 0.3-0.7 for normal sampling.

void WalkingPerturber::perturb_subset(
    Pose const &, IndexList const & residues, ClosureProblemOP problem) {

    for ( core::Size const residue : residues ) {
        Real phi = problem->phi(residue, DEGREES) + magnitude_ * gaussian();
        Real psi = problem->psi(residue, DEGREES) + magnitude_ * gaussian();

        problem->perturb_phi(residue, phi, DEGREES);
        problem->perturb_psi(residue, psi, DEGREES);


overall running these commands and looking at the results this all looks expected to me. coupled moves is not designed for large scale backbone moves.

here's an example i don't think you tried, where i mutate a small to large on the interior of the protein while allowing the shell to repack


~/rosetta-main/source/bin/coupled_moves.default.linuxgccrelease -s 2ilk_WT_relaxed_0.pdb -nstruct 1 -ex1 -ex2 -extrachi_cutoff 0 -mute protocols.backrub.BackrubMover -linmem_ig 10 -resfile resfile4 -exclude_nonclashing_positions -coupled_moves:ntrials 100 -coupled_moves:mc_kt 2.4 -coupled_moves::backbone_mover backrub -out:suffix _A134W

protocols.moves.TrialCounter:          RESIDUE trials=    100;  accepts= 0.4000;  energy_drop/trial=  -2.03040

pymol commands:

set cartoon_flat_sheets, off

set cartoon_side_chain_helper, on

select around_134_in, byres((2ilk_WT_relaxed_0_A134W_0001_last and resi 134) around 5 and n. ca and 2ilk_WT_relaxed_0)

select around_134_out, byres((2ilk_WT_relaxed_0_A134W_0001_last and resi 134) around 5 and n. ca and 2ilk_WT_relaxed_0_A134W_0001_last)

show sticks, around_134_in around_134_out

then for example you could design the shell around_134 ALLAAxc and probably observe some particular sequence changes to accomodate the W which is too big for that space.

Tue, 2021-02-23 10:09

A134W attachment

Tue, 2021-02-23 01:34

I'm not sure what your goal is, but LoopModeling might be better for large scale movements?

Or CoupledMoves with Fragment KIC? I don't see that in your examples. A fragment library may enable that 38-45 loop to rebuild and pull those tryptophans out of the interior. But for that Trp example you show, that large scale of movement would probably best be addressed by rebuilding the loop from scratch with LoopModel.

Tue, 2021-02-23 02:05

Hi again Amanda,


Thanks for such a detailed response. Let me run a few experiment with the info you've given and I'll get back to you with what I learn. 

I'll update this soon.



Sat, 2021-02-27 20:29