packstat in InterfaceAnalyzer

[Anonymous]

InterfaceAnalyzer manual refers to RosettaHoles (version 1, ProteinSci2009) for details about the metric packstat. But is the RosettaHoles score calculated by InterfaceAnalyzer only for the interface, or for the whole complex? (Current holes application is version 2, thus can not test it myself.) If it is calculated only using the interface residues, could it include the voids not at the interface by accident (voids formed by interface residue side chains otherwise would have been filled by residue not included in the calculation)?

TIA!

[Anonymous]

Your other question disappeared, but the standard is negative is better, thus ” ddG_ = complex_score – separated_score;”

For packstat, the returned value is a per-residue average over the residues in the interface set. It won’t have accidental voids – it’s calculating on the whole pose and returning only over the residues you wanted. In my experience, almost all interface voids are solvent-exposed, and thus packstat ignores them (so I don’t find it a useful metric here).

[attesor]

default value to “ignore_waters” is “false”.
ignore_waters | false | B| Do not abort if HOH water residues are found in PDB file; instead, ignore them.

fixbb complains about the unrecognized HOH unless I tell it to “-ignore_waters true”

[attesor]

Thanks for the answer!

Yes, I deleted my original other question, which was:
dG_separated = G_complex - G_separated or the other way around ?
I was not sure because in the manual it says this value is “binding energy”, which obviously betrays its name “dG_separated” (binding vs. separated . But then I did a simple calculation of energy for monomers and complex and got the same answer as in your reply.

I am very interested in how to ask Holes to return only scores over the residues I want. I believe I have only Holes2 at hand.

[Anonymous]

I’ve never been clear on the distinction, if any, between packstat and the holes score. Apparently packstat can be calculated per-residue. I don’t know if Holes or Holes2 supports that. I’ve sent this along to a couple of folks who might know.

[akhmelin]

In response to your question about calculating the holes score:
Holes1 can do its calculation on a per residue basis. It returns a vector with a packstat score for each residue in a protein. You then iterate over the residues you want to look at, add up the values for each residue, then divide by the total # of residues you looked at. For an example you can look at the function: compute_interface_packstat( core::pose::Pose & pose ) within InterfaceAnalyzerMover.cc . You can find it in rosetta/rosetta_source/src/protocols/analysis/

[Anonymous]

The author says:

“Yeah they can either get an atomid map from the code in core scoring packing, or dump a pdb with per atom scores in the bfactor column by adding -holes:make_pdb to the default app.
You can give them my email if you want.
Will”

I have sent his email address to your forum-registered address.

[attesor]

Yes, just found it: it is also in the suppl of the Holes2 paper. Many thanks!

[attesor]

How do I include water when computing Holes2 scores?

I have a PDB with buried HOH. If I use parameters:

tried -remember_unrecognized_res true and -remember_unrecognized_water true: CAV spheres still generated around buried waters;
tried -remember_unrecognized_water true alone: ERROR: unrecognized aa HOH;
tried -ignore_water false: ERROR: unrecognized aa HOH;
tried -holes:water true: ERROR: unrecognized aa HOH;
tried -holes:water true and -remember_unrecognized_res true and -remember_unrecognized_water true: CAV spheres still generated around buried waters;

[attesor]

also tried -packstat:include_water true: ERROR: unrecognized aa HOH

[Anonymous]

Try fixbb with your waters to see if it reads them it at all from PDB. “unrecognized aa HOH” says to me that the PDB reader sees the waters and, well, doesn’t recognize them. Let me look in the database for HOH.params and check if it’s active by default and how Rosetta wants it “spelled”.

[Anonymous]

The only water types I can find in the database are TP3 and TP5 waters. I could swear we had an “HOH” water somewhere, too, but I can’t find it.

Convert the waters in your input pdb to match the TP3/TP5 parameters (your choice). The files are at rosetta34/rosetta_database/chemical/residue_type_sets/fa_standard/residue_types/water. TP3 expects residue name WAT and atoms O, H1, and H2 (I pray O is sufficient…) and TP5 expects residue name TP5 with the same atoms.

Alternatively, copy TP3/5 into a new params file HOH.params, make it look like the waters you have, and add it to residue_types.txt or -extra_res_fa.

I’m pretty sure RosettaHoles is supposed to ignore voids large enough to fit a water molecule in its calculations, so as not to penalize for voids-that-aren’t-really-void.

[Anonymous]

The value of fixbb is it’s simpler than rosettaholes for diagnosing PDB read-in problems like we’re having…I can’t understand why the code knows to look for HOH if we don’t have an HOH type, though.

[attesor]

is this parameter relevant:
“cav_shrink | 0.7 | R| Cavity ball radii reduced by this amount”
In addition, does this mean I should add 0.7 to the radii of all the CAV spheres generated by specifying “-holes:make_voids”?

[attesor]

Is is useful for the diagnose: the waters I have only have oxygen:

HETATM 904 O HOH A2001
HETATM 905 O HOH A2002
HETATM 906 O HOH A2003

[Anonymous]

For this one you’ll definitely have to ask Will. You got his email address from me, right? If you remember, post whatever he replies here to archive it.

[attesor]

yes, I got the address and tried it. But I did not post his reply in the email and maybe that’s why I have not got any replies
btw, some developers are very annoyed if I ask questions both here and via email. So I am very careful now

[attesor]

maybe it only knows its name HOH so it can ignore it, but does not know enough details to read it in?

[Anonymous]

Will specifically asked me to pass it along to you – he just hasn’t had a chance to answer yet, I’m sure.

[Anonymous]

Try changing it to:

ATOM 904 O WAT
ATOM 905 O WAT
ATOM 906 O WAT

[attesor]

That SOLVES the problem when I specify “-holes:water”. Holes score also improves when I consider buried water. Kudos!

[Anonymous]

You might say it “solvates” the problem, instead (but only if you like terrible puns as much as I do).

[attesor]

yes, I would also say, that solvates the holes.

[Author]

Posts