Calculate residue-residue pairwise energies

Member Site › Forums › PyRosetta › PyRosetta – General › Calculate residue-residue pairwise energies

Viewing 3 reply threads
  • Author
    Posts
    • July 23, 2013 at 11:51 am #1674
      Anonymous

        I am trying to calculate all residue-residue pairwise energies for a given conformation. It doesn’t appear that these are stored when the score is computed, and that I need to access them directly for every residue pair. I have a few questions regarding this:

        1) There appear to be edge iterators for the energy graph obtained by pose.energies().energy_graph().edge_list_begin(). While this method is exposed to PyRosetta, it doesn’t appear that I can do anything with the iterator. In the C++ code the ++ operator is overloaded to advance the iterator, but there is no similar method for the Python code.

        2) Alternatively I can check all pairs of residues, which is kind of slow. With two residues rsd1 and rsd2 I can call the functions scorefxn.eval_ci_2b() and scorefxn.eval_cd_2d(). What is the difference between the “context dependent” and “context independent” energies (e.g. what is the context)? For precomputing energies on a fixed backbone which is correct? Are these weighted? And finally, how do these differ from the eval_*_2d_bb_sc() methods which compute backbone-sidechain energies?

        Jason

      • July 23, 2013 at 6:20 pm #9110
        Anonymous

          The residues-residue pairwise energies are being stored after each score computation, in the EnergyGraph object. (There’s no score re-computation going on by accessing edges there.)

          One thing you might be able to try is to initialize a utility.vector1 with the edge_list_begin() and edge_list_end() iterators. At least at the C++ level, the vector1 constructor should be able to take a start and end iterator and construct a list out of it. I don’t know if that functionality is exposed to the Python level, though.

          Past that, doing exhaustive pairwise enumeration is probably the way to go. I might recommend trying to use the find_energy_edge(n1,n2) method of the EnergyGraph object (which will just access the stored energies) instead of recomputing the energies with the scorefunction. Depending on the size of the EnergyGraph, and the complexity of the scorefunction, this may be quicker.

          Regarding “context”, this simply refers to the number of 10 Ang neighbors – i.e. how many other residues are surrounding a given residue. Context dependance allows for weighting certain scoreterms differently whether they’re buried or exposed, while maintaining the pairwise decomposability of the scorefunction during packing. Both are needed for scoring a fixed backbone structure.

          The eval_*_2b() functions evaluate the entire energy of the residue-residue interaction, whereas the eval_*_2b_bb_sc(), eval_*_2b_bb_bb() and eval_*_2d_sc_sc() function only evaluate those portions of the energies attributable to the backbone-backbone, backbone-sidechain, or sidechain-sidechain interactions. (All of these add the unweighted energies to the values already present in the energy map passed in.) The reason you’d want to break it down is that in situations like packing, where you have a fixed backbone and multiple sidechains at each position to consider, you can evaluate the backbone-sidechain contributions once, and only combinitorially sample the sidechain-sidechain interactions. If at any one vevaluation you’re doing single structure scoring (not doing combinatorial enumeration of differing sidechain identities) there’s probably not going to be much gain from splitting out the bb/sc contributions.

        • July 23, 2013 at 11:21 pm #9114
          Anonymous

            Thanks, this clears things up. Unfortunately, it doesn’t appear that initializing vector1 with iterators is exposed to Python.

            Jason

          • July 25, 2013 at 7:05 pm #9128
            Anonymous

              Jason,

              I have double checked and you are right, currently there is no proper bindings for iterator-like objects. So at the moment there is no solution for this. I will add this to my list but it will probably be a while until this is fixed.

              Best,

            • July 25, 2013 at 4:28 pm #9125
              Anonymous

                Sergey may be able to help. I have emailed him; you should hear from him soon.

                -J

            • Author
              Posts
            Viewing 3 reply threads
            • You must be logged in to reply to this topic.