You are here

Problem with hotspot constraints.

7 posts / 0 new
Last post
Problem with hotspot constraints.
#1

Hi everybody,

I have taken the example on simultaneous stub placement, and modified it a bit.
In this example, one sidechain is forming a hydrogen bond. I don't need this
part so I removed it from the script. I just need to transplant two hydrophobic hotspots.
The original script works great, but when I modify it, I get problems with
the hotspot constraints. Basically, it seems they are not applied anymore.
The message I get in the output is:
"protocols.hotspot_hashing: Applied 0 hotspot constraints to the pose".
Before this message, the stubs seem top be read without any issues:
"protocols.hotspot_hashing: Read 125 stubs from stubsall.pdb"

Any ideas what could go wrong? I have attached both xml files, the changed one
(placed_simult.txt) and the original example (four_stubs_Oct09_new.txt).

Thanks,

Jarek

AttachmentSize
place_simult.txt3.56 KB
four_stubs_Oct09_new.txt5.74 KB
Post Situation: 
Wed, 2012-10-17 03:22
jarek

This is currently bouncing around the Baker lab, looking for someone who knows how to debug it.

Wed, 2012-10-17 13:37
smlewis

Eva tells me:

"As it sounds to me, the scaffold protein is too far away from teh stubs, that is when the constraints go to 0.
look at stubs and target protein to make sure, they are together. try to find a control for you test case, turn of docking and test again.

otherwise, you can turn of all filters in teh mover and increase the distance threshold to see whether it works and then slowly work yourself towards reasonable lower values. this protocol is very sensitive."

Thu, 2012-10-18 09:50
smlewis

Hi, thanks for the hints. I checked the performance of the example script from rosetta_tests to see how sensitive it is to the undocking of the initial complex. I took the input file 1l6x.min.pdb removed the ligand away by around 30A, rotated the paratope so that it faced the solvent, and still, the script is able to identify the same complex. So it doesn't seem the distance is the problem, since protein is first docked on the target before the constraints are applied. It only takes more time to get to the same result. There are poses that do not result in a complex that fulfills the requested filters, but if I look at the output, the hotspot constraints are imposed correctly: "Applied 30 hotspot constrains to the pose".

What distance threshold do you exactly mean? I can't find anything like a distance threshold in SetupHotspotConstraints.

Does the structure has to be prepared in some special way, except for the normal relaxation procedure?
Or maybe I'm doing something wrong with the stubs? I have prepared them by just redocking the hotspot aminoacids assuming they
have to reform the native interactions. Do they have to be additionally minimized?

I ran my script and the example in parallel and compared the outputs. The first time they significantly differ is here:

protocols.hotspot_hashing: Read 128 stubs from stubsall.pdb
protocols.protein_interface_design.movers.SetupHotspotConstraintsMover: applying hotspot hashing constraints to pose with cb_force weight of 0.5, apply ambiguous constr
Setting bacbkone_stub_constraint weight in scorefxn ddg_scorefxn to 1
Setting bacbkone_stub_constraint weight in scorefxn score12 to 1
Setting bacbkone_stub_constraint weight in scorefxn score12_coord_cst to 1
Setting bacbkone_stub_constraint weight in scorefxn score4L to 1
Setting bacbkone_stub_constraint weight in scorefxn score_docking to 1
Setting bacbkone_stub_constraint weight in scorefxn score_docking_low to 1
Setting bacbkone_stub_constraint weight in scorefxn soft_rep to 1
Skipping resetting of backbone_stub_constraint weight in stub_docking_low which is already preset to 10
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.476648 0.205771 -0.854673 -0.800324 0.503816 -0.325039 0.363714 0.838944 0.404826 35.8251 6.97341 0.575569
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.476648 0.205771 -0.854673 -0.800324 0.503816 -0.325039 0.363714 0.838944 0.404826 59.766 32.7514 -18.4594
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.476648 0.205771 -0.854673 -0.800324 0.503816 -0.325039 0.363714 0.838944 0.404826 35.8251 6.97341 0.575569
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.476648 0.205771 -0.854673 -0.800324 0.503816 -0.325039 0.363714 0.838944 0.404826 59.766 32.7514 -18.4594
core.pack.task: Packer task: initialize from command line()
core.pack.interaction_graph.interaction_graph_factory: Instantiating PDInteractionGraph
core.pack.pack_rotamers: built 21 rotamers at 21 positions.
core.pack.pack_rotamers: IG: 54292 bytes
protocols.hotspot_hashing: Associated stubs with scaffold chain 2
protocols.hotspot_hashing: Making hotspot constraints...
protocols.hotspot_hashing: Applied 0 hotspot constraints to the pose.

I can't find what the values after Jump (after/before) mean. Are they maybe anomalous in some way?

Thanks for your help

Jarek

Fri, 2012-10-19 05:43
jarek

Hi jarek,

I guess Eva is right about that "the scaffold protein is too far away from the stubs, that is when the constraints go to 0." The reason is that it is not appropriate to remove the PlaceStub mover in your script. The initial low-reso docking cannot guarantee your chain2 is near enough to the hotspots. That is why you see a PlaceStub mover before StubScore filter, which is used to drag your docking poses to the top of HotSpot 1 (Gln here). Because HotSpot constraints is very sensitive to position and distance, although there is a hs term in docking score, you may not expect the low-reso docking can really take you to the hotspots. I suggest you dump all the low-reso docking poses and visualize them with the hotspots residues to check where they are.

Sat, 2012-10-20 13:23
xfliu

Hi, Thanks for your comments.
I tested a native complex, where the stubs perfectly match with the scaffold, to see if this really was a problem of distance and I got the same error message.
Fortunately, I have already figured out what was the issue. It was the REMARK line in the stub files. I automatically neglected it, thinking it was
just a comment line, that was not necessary for the correct functioning of the protocol. It turns out, adding this line solved my problem, and vice versa, removing
this line in the example resulted in the same error message.
Maybe would be a good idea to add some info on the stub file format in the manual?

Thanks for help

Jarek

Tue, 2012-10-23 00:44
jarek

Glad to know you have the problem solved. The remark lines are used to store the stub bonus values, which are set as a constant value of -3.0 in make_stubs_from_pdb.sh. I guess that is only a flag of good hotspots. Lack of negative bonus vales will lead to rejecting the hotspot residue in the stubset. That's why you saw the HS residues were read normally but none of them were applied as the constraints. There was a tracer alert for this problem in the code, but they had it commented for some reason.

Tue, 2012-10-23 03:22
xfliu