Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › Rosetta dock irmsd
- This topic has 5 replies, 2 voices, and was last updated 8 years, 12 months ago by Anonymous.
-
AuthorPosts
-
-
April 26, 2015 at 8:51 pm #2186Anonymous
Hi Rosetta people
I have an odd problem concerning the interface rmsd output from rosetta dock.
I have two structure outputs from different runs. Only difference is using saxs as restrain in one run otherwise the scripts are identical.
I get better irmsd from the saxs run (0.333 vs. 1.116) but when looking at the structures there is barely any difference, I have checked rotamers as well.I have looked at the fold tree to see if there is a problem in interface recognition between the two. The residues number for the jump is set as the center of each protein (that is center of protein, center of “ligand”). As I understand it there is no problem.
I use the “-native” flag too identify the native structure for rmsd calculation.
I cannot figure out how Rosetta would evaluate these two structures different?
Any chance you have a clue for where to look for the problem???
I don’t seem to be able to upload the PDB files or log file as the exceed the file size allowed by your server.
Best regards
Pernille
-
May 3, 2015 at 8:21 pm #10997Anonymous
Hi again.
I have realized the problem. Apparently Rosetta script ignores the -native flag. So am rather confused what it uses for comparison as there is very little difference betweein the native and the input structure (bound versus unbound x-ray structures), but am still getting variable rather low irmsd values….???????Using the Interface analyzer I get more reasonable rmsds (and quite higher) (compared by aligning the interface recognized by the Interface analyzer tracer in Pymol with cycles = 0, ie no optimization). I have tried with both bound and unbound as native to see if this is the issue but this gives very little difference).
Next odd question. The “interface energy” in docking and the “binding energy” from interface analyzer. They are defined quite similarly as the compex minus the seperated components, though I understand there is a difference and dG is preferred. Even though dG is preferred I cannot understand how a structure can have a negative I_sc from docking while it gets a positive dG. (Notice I use saxs scoring in the protocol).
Protocol:
For a two chain structure
with flags:
-restore_pre_talaris_2013_behavior
-overwrite
-use_input_sc
-ex1
-ex2
-corrections:score:use_bicubic_interpolation true
-out:file:score_only struct_IA_1.sc
-native native_bound_re.pdb
-out:no_nstruct_label
-residues:patch_selectors CENTROID_HA
-score:saxs:ref_spectrum struc_err.dat
-score:saxs:q_min 0.01
-score:saxs:q_max 0.3
-score:saxs:q_step 0.01
-score:patch saxsI hope you can clarify some of these questions for me, and its not too many in one.
Best regards
Pernille -
May 6, 2015 at 1:58 pm #11005Anonymous
Hi Moretti
Thank you for your answer.
In regards to using the interface analyzer (IA) with score12 with and without saxs, I have tried different approaches.
1)No saxs flags, just regular score12 scoring
2)as above but providing the patch (fastsaxs=0.5) and saxs flags as the protocol described above
3) inserting a reweight score with fastsaxs = 0.5 with and without the saxs patchMost scores are completely the same. Importantly i_rmsd and dG seperated are the exact same.
The fastsaxs score is only present in the score file if the patch is present even if I reweight the score12 with fastsaxs = 0.5.
Odd things that happen when fastsaxs is on (0.5):
rama and omega dissapears
hbond_rr_bb and p_aa_pp doubles in value
Why would these values be affected by a fastsaxs value which is basically just a kind of chi^2 value for the fit between the caculated curve from Rosetta and that supplied by me? The fastsaxs scores are above 150 which is redicilously high by as this is scaling with the weight I guess I could simply set the value higher – i.e. lower restraint.
Regarding the docking i_rmsd issue, there is no doubt that it is ignoring the -native flag as trying to use a completely different structure is not affecting the docking run or outputs. Doing the same with the Interface analyzer results in fault. If one compares the irmsds I get from IA and docking they are very different. This goes for docking runs without saxs as well. My (very) basic docking scripts is:
DOCKING MOVERS
Speeds the move from centroid to full atom mode
Would i need to specify the Irmsd filter in the docking protocol as done in IA even though it outputs all the same rmsd values as the traditional docking protocol?
What you write above is that the saxs score somehow affects the interface energy? Ah as interface energy is total energy of complex minus seperated proteins. But from IA I believe from above results that I just get a scoring of the complex from fastsaxs. But then it makes sence why there is a difference between docking and IA.
Thank you again
Best
Pernille -
October 8, 2015 at 11:37 am #11262Anonymous
Hi again
I never got an answer on the above so decided to put it slightly different:
What is the difference between the Irmsd from docking and the Irmsd from Irmsd filter.
I decided to simply add the filter to the above script (under filters) and add_mover after the other three.
I get two very different Irmsds as seen below. One thing is that they are different, but they do not seem to correlate. Could you telll me the difference? I can find the explanation on the Irmsd filter but not on the docking. I have been searching in the code but I am absolutely not an expert reading code.
I hope you can help as the docking Irmsds does not correlate well with actual structures viewed in Pymol.
Best regards
Pernille
SEQUEN CE: Docking Irmsd Filter SCORE: total_score rms Fnat I_sc Irms Irmsd cen_rms dslf_ca_dih SCORE: -1501.19 4.695 0.278 -4.339 2.777 12.512 18.719 1.407 SCORE: -1482.3 5.826 0.421 -6.836 1.157 9.727 20.727 1.407 SCORE: -1500.35 7.168 0.307 -5.402 2.447 4.577 6.947 1.407 SCORE: -1502.44 3.683 0.355 -9.372 1.599 3.923 3.896 1.407 SCORE: -1500.99 6.092 0.259 -4.219 3.069 12.043 17.732 1.407 SCORE: -1493.58 2.294 0.475 -10.909 1.06 11.796 18.605 1.407 SCORE: -1500.65 5.132 0.364 -8.459 1.697 4.821 7.822 1.407 SCORE: -1493.29 4.903 0.2 -4.019 2.876 7.622 14.178 1.407 SCORE: -1462.37 3.889 0.538 -7.141 1.563 12.025 18.599 1.407 SCORE: -1490.14 5.874 0.455 -3.728 1.369 9.594 16.128 1.407 SCORE: -1502.22 5.013 0.419 -9.561 2.076 2.451 2.183 1.407
-
May 5, 2015 at 10:14 pm #11004Anonymous
Generally, when a protocol computes an rmsd but doesn’t have or can’t read the native file, it uses the input structure as its “mock” native – I’m not sure if that is able to explain the results you see. (Looking at the code, the IRmsd filter should be obeying the -in:file:native flag.)
On the scoring discrepancy, one issue you may be running into is that you’re supplying the saxs patch on the commandline, but supplying the interface analyzer with plain score12 – this wouldn’t have any saxs scoreterms. If you want to include saxs terms, you’d need to pass a modified scorefunction to the InterfaceAnalyzer mover.
If you had saxs on during the docking scoring, you’d get a rather positive score in the apo state, as the separated complex is a poor fit for the complex’s envelope. So when you compute the difference, the bound state will be (comparatively) negative, although in absolute terms it may still be poor. When you use plain score12, you don’t get the bad saxs score from the apo state, leading to the interface looking comparatively much worse. So I think the plain score12 scoring is going to work better for you for evaluating the quality of the interface, as you don’t get noise from scoring the apo state with the complex’s saxs spectra.
-
October 12, 2015 at 10:10 pm #11265Anonymous
Oops, sorry for letting your questions fall through the cracks.
The two methods should be using the same function to calculate the value (protocols::docking::calc_Irmsd()). The difference must arise in one of the parameters being passed to the function: the pose, the reference pose, the score function, or the movable jumps values.
The structure on which you’re calculating the Irms obviously will make a difference. If the structure changes (e.g. it gets repacked, relaxed or minimized) between the time you run the Docking protocol mover and the time you run the Irmsd filter, then your Irms will change. Likewise with your reference structure: if you’re providing a different native (with -in:file:native) or not providing a native structure (and thus using the input as a “mock native”), then your rmsd will be different.
It’s unlikely to be the score function used, as that’s only used in a round-about fashion to get the residue-residue distances, and probably isn’t an issue.
The other thing that might change things is your interface specification (the movable jumps). For the filter you specify which jump you’re using for the interface with the “jump” option. The interface will be computed on the parts of the protein upstream and downstream of that jump. If this is different from what you’re using in your docking specification, then the calculation will be over a different interface, and thus different. But it looks like you just have the two chains, so you should have just the single jump. – But that might change if you’re doing strange things like adding virtual roots or doing symmetry. I wouldn’t expect that to be an issue here, but you never know.
(Note that the interface calculation is special cased for symmetric proteins, or proteins where the jump is connecting a ligand or a nucleic acid, so if that’s the case for your system, things may get interesting.)
If I had to guess, I’d say the difference in Irmsds is because of a difference in what’s considered “interface”. Unfortunately, there’s not a good way of getting that information out with default Rosetta. However, if you’re willing to do a quick re-compile, you should be able to add a “interface.show( native_docking_pose );” to the calc_Irmsd() function in src/protocols/docking/metrics.cc at around line 239, right after the “interface.calculate( native_docking_pose );” line. This should print out a list of interface residues (to the “core.conformation.Interface” tracer) each time the calculation is called. You should then be able to see if there’s a difference between the Docking calls and the IrmsdFilter calls.
If it’s still a conundrum, you might have to put together a short example with complete input & commandline, and post it here so I can play around with it locally on my machine.
-
-
AuthorPosts
- You must be logged in to reply to this topic.