Fold tree C->N: RosettaScripts

Member Site Forums Rosetta 3 Rosetta 3 – Applications Fold tree C->N: RosettaScripts

Viewing 4 reply threads
  • Author
    Posts
    • #1516
      Anonymous

        Hi,

        If I have a protein of size nres. And I do small moves at say residue x (< nres). Is there a way to keep residues x+1..nres at the starting coordinates, but allow residues 1..x to move? x+1..nres forms an interface with its dimer partner and hence I do not want to move those residues. Thanks,
        Aroop

      • #8408
        Anonymous

          You need to set up a FoldTree such that you have e.g. a polymeric connection from 1 through x, but have a jump from 1 to x+1 followed by a polymeric connection from x+1 through nres.

          Foldtree manipulation in RosettaScripts is rather limited, but you might be able to use the AtomTree mover. http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#AtomTree The normal docking_ft option is not quite what you want. I would instead suggest that you use the pdb_num/res_num, anchor_res, connect_to & connect_from options to explicitly set up the connections.

          The other option is to simply flip your complex. Place the static chain first in the PDB (e.g by using a text editor), and the movable chain second (you don’t even need to change the PDB chain ids). This would make it so that any changes to the movable chain wouldn’t propagate to the static chain, even with the default foldtree.

        • #8409
          Anonymous

            In code, this is trivial:

            fold_tree.reorder(pose.total_residue());

            is all you need. (Technically you need to extract the FoldTree to work on it, and re-apply it to the pose, so three lines if you’re feeling pedantic.)

            In RosettaScripts…the idea of “apply this fold tree to my Pose” is simple, but there’s no Mover I can find for it. Broadly, protocols/init/init.MoverCreators.ihh shows all Movers with Creators (thus, all Movers that work with RosettaScripts). The only one with an appealing class name is SetAtomTree. Going back to the documentation, I found http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#AtomTree

            This appears to allow you to apply your own FoldTree. Looking into the code, it looks really fragile; given that there is an IO operator for FoldTree I wish it just used that. It forcibly defines the fold tree root as residue 1, so you’ll need to reverse your PDB chain order (just cut-and-paste to reverse which chain is first). I think you’d use something like:

            {AtomTree name=(&string) simple_ft=0 docking_ft=0 pdb_num=chain_1_end connect_to=CA anchor_res=chain_2_end connect_from=CA/}

            I can draw the fold tree you need, and help you interpret text fold trees, if you have something that sort-of works. I don’t know how to baby the SetAtomTree mover into better behavior, though. It would also be easy to gut/copy an existing Mover and replace it with code that just reverses the FoldTree for a one-shot use.

          • #8411
            Anonymous

              After further reflection, it’s frustrating that RosettaScripts doesn’t already have this behavior. I think there’s a good reason nobody ever wrote the Mover you need. Movers that RosettaScripts uses fall into three classes:

              A) Movers for whom the FoldTree is totally irrelevant,
              B) Movers that will just reset the FoldTree to be whatever they needed anyway,
              C) Movers that are too fine-grained (SmallMover) to be used in RosettaScripts directly 99% of the time.

              Your need is the rare case C.

            • #8417
              Anonymous

                Dear Steven & Rocco,

                Thank you for the feedback. Given the very special scenario would it best if I hacked the AtomTree mover to impose a custom fold tree from with C++ ?

                @Steven: Can you please point me to where SetAtomTree is defined and passed to the pose?

                Thank you,
                Aroop

              • #8410
                Anonymous

                  I don’t think flipping the complex _alone_ will work – he needs a fold tree which initiates folding the moving chain from its C-terminus because he wants the C-terminus of the first chain to not move relative to the other chain.

                • #8414
                  Anonymous

                    Sorry, you’re right – I slightly misinterpreted the geometry of the problem.

                  • #8423
                    Anonymous

                      If you’re comfortable changing the SetAtomTree mover (AtomTree is the XML name – it’s actually protocols::protein_interface_design::movers::SetAtomTree in the code) and recompiling, that’s probably a decent way of doing things.

                      To get the foldtree from the pose, you’d simply do something like:

                      core::kinematics::FoldTree fold_tree = pose.fold_tree();

                      To set it, you’d do something like:

                      pose.fold_tree( fold_tree );

                    • #8430
                      Anonymous

                        Sorry, the forum stopped emailing me about replies to threads.

                        in src/protocols/protein_interface_design/movers/SetAtomTree.cc

                        replace the contents of the function “SetAtomTree::apply( core::pose::Pose & pose )” (line 162) with the attached text.

                        EDIT: ack! No attachments button! and the code gets eaten because of angle brackets. Replace the { in this text with the right-pointing angle bracket.

                        core::kinematics::FoldTree new_ft(pose.fold_tree());
                        TR{{“Previous fold tree: “{{pose.fold_tree(){{‘n’;
                        new_ft.reorder(pose.total_residue());
                        pose.fold_tree(new_ft);
                        TR{{“New fold tree: “{{pose.fold_tree(){{std::endl;
                        return;

                    Viewing 4 reply threads
                    • You must be logged in to reply to this topic.