# DockingHighResLegacy repacks all sidechains on first apply(), interface sidechains on subsequent apply()

5 posts / 0 new
DockingHighResLegacy repacks all sidechains on first apply(), interface sidechains on subsequent apply()
#1

[Using PyRosetta.ScientificLinux-r47452.64Bit]

 docker = DockingHighResLegacy(jump, scoreFxn) docker.apply(pose)

When I use the above in a python script, I get:

...
protocols.docking.DockingHighRes: in DockingHighRes.apply
protocols.docking.DockingHighRes: ::::::::::::::::::DOCK_MCM:::::::::::::::::::
core.pack.task: Packer task: initialize from command line()
core.pack.interaction_graph.interaction_graph_factory: Instantiating DensePDInteractionGraph
core.pack.pack_rotamers: built 4141 rotamers at 256 positions.
...

which repacks sidechains of my entire structure. However, the next time I use .apply(pose), I get:

...
protocols.docking.DockingHighRes: in DockingHighRes.apply
protocols.docking.DockingHighRes: Using user-defined TaskFactory.
protocols.docking.DockingHighRes: ::::::::::::::::::DOCK_MCM:::::::::::::::::::
core.pack.task: Packer task: initialize from command line()
core.pack.task: Packer task: initialize from command line()
core.pack.task: Packer task: initialize from command line()
core.pack.interaction_graph.interaction_graph_factory: Instantiating DensePDInteractionGraph
core.pack.pack_rotamers: built 30 rotamers at 2 positions.
...

which just repacks the interface.

I see in Rosetta 3.3's DockingHighResLegacy constructor that "init_task_factory_=NULL" is active, while in ver 3.2.1 "//init_task_factory_=NULL".

Is there a way to turn off pre-packing in the DockingHighResLegacy class? Is there now a better class to dock with?

Post Situation:
Wed, 2012-02-22 22:46
msellers

Hello,

I would definitely recommend using the standard DockingHighRes mover for docking rather than the legacy version. I'm not quite sure how to prevent the initial full-repack of DockingHighResLegacy... You could create a packer task and set "or_include_current" to True (task=TaskFactor.create_packer_task(pose); task.or_include_current(True)). This will ensure that the original rotamers in your pose are considered during packing; so if you are starting from an xtal structure or something stable there is a good chance Rosetta won't touch many of the side chains. The reason the full-prepack is necessary is to remove any high-energy clashes from the initial structure, if you skip this step you may get poor results as a result of rounding errors (during docking the total energy drop might be minuscule compared to the high energy clash). Hope this helps!

Mike

Thu, 2012-03-01 20:58
mpacella

Appreciate the help.

I was using DockingHighResLegacy(...) because I am unable to instantiate DockingHighRes(...) with PyRosetta. Have you been able to get this working?

As for repacking sidechains, I'm doing this before docking. Since it is stochastic, I would rather not have the Docker repack all of them on its own before each run. This leads to docked structures that are not consistent, though only slightly.

I'm currently using DockingHighResMCM(..) and manually minimizing after.

Sat, 2012-03-10 11:44
msellers

7 years later，i found the same problem，do u know how to instantiate DockingHighRes with PyRosetta?

Sun, 2019-03-17 06:18
zhangying1990

One option you might try is to initialize the mover through the XML interface, as that is often better tested/supported than the direct Python initialization.

An example of how to use the XML interface to initialize a mover can be found at https://github.com/RosettaCommons/pyrosettascripts_demo/blob/master/data_generation/ddG_pssm.ipynb (You would just need to adjust the tags for the mover you're interested in initializing.)

Thu, 2019-05-09 15:03
rmoretti