Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › ORBITAL records in self generated .params (ligands)
- This topic has 9 replies, 3 voices, and was last updated 10 years, 6 months ago by
Anonymous.
-
AuthorPosts
-
-
March 6, 2014 at 3:22 pm #1847
Anonymous
Hi all,
how do I get the ORBITAL records (that can be found in predefined normal AAs .params)
for a self generated ligand?
The molfile_to_params.py does not seem to cover that?!thanks
ast
-
March 6, 2014 at 3:45 pm #9861
Anonymous
I forwarded this to Steven Combs (the orbitals developer) but I think the answer may be “manually”.
-
March 7, 2014 at 9:21 am #9866
Anonymous
Thanks.
To add a little background:
I want to design a ligand binding pocket using enzdes. The ligand has a carboxy group (I tried both OOC+OH and OOC+OOC).
However, looking at the deconvoluted single residue energies my ligand always shows 0 for the fa_pair energy.
Do I have to invoke the electrostatics explicitly? I always thought that a simplified Coulomb model (like the one for ligand docking) is used for the ligand based on the Atomtypes and charges of the ligand. Or do I really need to define the orbitals for my ligand?
Thanks again -
March 10, 2014 at 9:47 am #9879
Anonymous
First of all, thank for all the background.
I checked again in my enzdes outputs: no fa_elec or hack_elec. I attached all relevant files. Maybe I’m missing something?
One additional information, that might be crucial: My System has two chains PLUS one ligand chain. Thus for enzdes he tells me “WARNING: the input pose has more than two chains, interface score reported in scorefile might not be accurate.”, which is ok for me, since I rescore anyway. However, I want to make sure enzdes “sees” the ligand in the design process correctly. For all non electrostatic interactions this seems to be the case.
I prepared my ligand with bcc charges (see attached). Both oxygens have large negative charges, for comparison I checked them against the GLU.params of fa_standart, 3.4 database (only diff I see between these lines is the MM atom type, which should not matter right ?:
GLU:
ATOM CD COO CC 0.62
ATOM OE1 OOC OC -0.76
ATOM OE2 OOC OC -0.76
MY:
ATOM C10 COO X 0.64
ATOM O2 OOC X -0.56
ATOM O1 OOC X -0.61I also checked on the enzyme_design demo of 3.4 and could not find any hint of an elec value in the deconvoluted single residue energies. According to what u said fa_pair is 0 for the ligand. Where are this “elec” values hidden, I am pretty sure I miss something here, just dont know what.
And one last question. Talaris2013 … is part of 3.5?
Thank a lot!
-
March 7, 2014 at 4:16 pm #9868
Anonymous
First off, I’ll paraphrase what Steven’s answer will be to the ORBITALS question. You only need the orbitals information if you’re going to be using a scorefunction which uses the orbitals scoreterms, and none of the standard scorefunctions do this. Secondly, the explicit ORBITALS lines in the scorefunction are from a previous way of assigning orbitals. The newer methods actually can assign the orbitals automatically. – I believe the orbitals paper has just been submitted, so details will be forthcoming.
Regarding the fa_pair energy, fa_pair is a statistical potential regarding the distances between “action centers” of amino acids. As we don’t have enough information to get decent statistics with your ligand, it’s very hard to come up with an fa_pair energy for it, hence the zero energy.
At any rate, we’ve actually found that using a Coulombic electrostatics model (called fa_elec in recent weekly releases, “hack_elec” in older versions) does a better job than fa_pair. That was one of the changes that was made going from score12 to talaris2013. The current default scorefunction doesn’t use fa_pair at all, and instead uses fa_elec for everything. (If you’re under the pre-talaris regime, ligand docking and enzdes used fa_pair for protein-protein interactions, and fa_elec for protein-ligand interactions.)
To get electrostatic on your ligand, all you need to do is have electrostatics turned on in your scorefunction (as talaris2013 does, and as the enzdes and ligand docking scorefunctions do.) and have the appropriate partial charges annotated in your params file. These are the fifth column of the ATOM line. Which partial charges you should use for ligands is a little fuzzy. AM1-BCC charges (e.g. from OpenEye Omega) have been recommended, and some people use Gasteiger charges (e.g. from OpenBabel). If you do molfile_to_params.py with a mol2 file, it will use the partial charges listed in the file. If you use a mol/sdf file (or don’t have charges in your mol2 file), then molfile_to_params.py will do a heuristic charging based on Rosetta atom types. In any event, you can always use a text editor to change the partial charges in the params file, if you so desire. (Pretty much any decent charging scheme will stick a concentration of negative charge on the carboxy group, so in that respect the details of the charging scheme may not matter too much.)
-
March 10, 2014 at 9:48 am #9880
Anonymous
thanks for the infos … however, I dont find the elec term. See the other post.
-
March 10, 2014 at 3:17 pm #9881
Anonymous
Right, I forgot that in 3.4 and earlier you had to manually add the hack_elec term to the enzdes.wts file if you wanted it. (Which you probably did.) We realized this was a little silly, and so for 3.5 and later we added it to the default enzdes.wts scorefile. If you want to use Rosetta3.4 and include hack_elec, you need to add the line “hack_elec 0.5” to rosetta_database/scoring/weights/enzdes.wts. Alternatively you can make a patch file with just the line “hack_elec = 0.5”, and then pass that file in with the -score:patch option everytime you run the enzdes application.
Talaris2013 is not part of 3.5. You need to use one of the weeklies in order to get talaris. (It’s worth pointing out that on the benchmarks, weeklies with talaris do as good or better than 3.5 (or 3.4) with the enzdes.wts file. Note that due to varying defaults, if you’re using the enzdes application, you’ll want to explicitly call for the talaris scorefunction with “-score:weights talaris2013” and also use “-ligand:old_estat false” to make sure the fa_elec term gets calculated for protein-protein interactions and not just for protein-ligand interactions.)
-
March 10, 2014 at 5:44 pm #9882
Anonymous
jep, solves the issue, thank a lot …
But you should definitely put that in the documentation of enzdes.
As for talaris, can you give any rough speed estimate. With the hack_elec calculation time roughly doubles. Is this faster with the talaris sf?Thank again
cheer
-
March 11, 2014 at 12:01 am #9888
Anonymous
I offhand can’t recall an extensive speed comparison, although I guess it would be similar to adding in hack_elec to older score functions. (From what I understand, going to an atomistic Coulombic calculation instead of the per-residue fa_pair energy is the main source of the slowdown.) 1.5-2x slowdown seems to be the right ballpark, although I believe it depends on the particulars of the protein being scored. — The consensus is that the improvement in quality is worth the calculation slowdown, though.
-
March 13, 2014 at 2:17 pm #9894
Anonymous
Thanks again.
-
-
AuthorPosts
- You must be logged in to reply to this topic.