Allowing cysteines to repack

Member Site Forums PyRosetta PyRosetta – General Allowing cysteines to repack

Viewing 2 reply threads
  • Author
    Posts
    • #1336
      Anonymous

        Hello all, I am working on using PyRosetta to improve a homology-derived protein structure, in which the disulfide bonds are not in their ideal configuration. After playing around with the refinement.py script in the tutorials, I noticed that it was leaving the disulfides untouched in the output results. I noticed in the manual (under TaskFactory) that PyRosetta/Rosetta disables cysteine repacking by default. It wasn’t clear to me how to disable this behavior. I tried the following after initializing the packmover:

        rr = RestrictResidueToRepacking()
        rr.include_residue( 4 )
        rr.include_residue( 13 )
        tf = standard_task_factory()
        tf.push_back(rr)
        packmover.task_factory(tf)

        …with residues 4 and 13 being the bonded cysteines. It slows the script down tremendously, leading me to believe that I am doing it incorrectly (or this is something I shouldn’t be touching).

      • #7380
        Anonymous

          I’m not too experienced with disulfides, but my understanding is that the default Rosetta packing machinery does allow the disulfides to repack (there is, after all, a NoRepackDisulfides task operation). The trick is that other movers, utility functions, etc. can impose their own additional behavior on disulfides on top of the default behavior. (For example, I know the standard Enzdes machinery has special considerations for disulfides.) That’s what you’re running into with the standard_task_factory() utility function (see below for more).

          Regarding your example, the major thing to keep in mind is that the task factory/task operations are restrictive only operations. That is, by default the tasks generated by a fresh task factory allow both design and repacking at all positions, and then each operation would then turn off design and/or repacking at that position. (Hence “restrict to” repacking.) So in your example, you’re designing all the positions, except for residues 4 & 13, which you’re specifying to repacking only. That’s the cause of the huge slowdown – the number of possible rotamer combinations is exploding, and the packer is taking more time in compensation to adequately consider them.

          Because of the restrictive nature of the task factory, if some other mechanism is setting disulfides to fixed, there isn’t any additional function you can call or task operation you can apply to set them to repack. Fixed/no repack is more restrictive than repacking, so once you’ve toggled no repack on, you can’t then turn it off again (or rather turn repacking on). The only option is to do things such that the no repack disulfides never gets triggered in the first place.

          You’re key issue is that you’re using the “standard_task_factory()” PyRosetta function. That’s equivalent to:

          tf = TaskFactory()
          tf.push_back(InitializeFromCommandline())
          tf.push_back(NoRepackDisulfides())

          The solution would be to create your own “non-standard” task factory by replicating that functionality, but without the “tf.push_back(NoRepackDisulfides())” bit. (If you’re not mucking around with setting the commandline options, the “tf.push_back(InitializeFromCommandline())” is superfluous as well.)

        • #7384
          Anonymous

            Thanks for the help! By the way, does the standard_task_factory() also use RestrictToRepacking()? It seems to be the case from your description.

          • #7385
            Anonymous

              In the version I looked at, it does not appear to be the case. Although some other item might turn it on.

              It never hurts to double specify a restriction, though. (That’s actually the reason for the restrictive-only behavior of the task.) So if you don’t want to design at any position, I would highly recommend explicitly setting RestrictToRepacking(), even if you suspect something else might also be turning it on.

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