- This topic has 3 replies, 2 voices, and was last updated 11 years, 10 months ago by Anonymous.
February 4, 2012 at 6:59 am #1155Anonymous
Aim: ab-initio protein-modeling-docking for proteins containing non-standard amino acids .
I was able to parameterize the new amino acids for Amber ff, which developed along QM calculations for also K-Br atoms, i.e., at higher level than 6-31G* and DFT in place of HF. It worked: the MD simulation showed protein stability along 15 ns by using a NAMD-CUDA cluster.
Then, I collected info from Rosetta.3.3 forum, especially about mol2 file -> Rosetta parameters, such as in the thread initiated by einew on 02/28/2011 on “Rosetta applications”.
Question: In Amber protocols, the mol2 file is not enough, it must be accompanied by a “frcmod” file for geometrical data. Is it any protocol about that? Once I hopefully succeed, I’ll post the scheme.
thanks for advice
February 5, 2012 at 9:40 pm #6620Anonymous
From a quick search, it looks like the Amber frcmod contains information about the various force field parameter specifications for that particular chemical entity.
Rosetta handles things slightly differently. The Cartesian coordinates for the particular simulation/run you are using are passed to Rosetta as a PDB file. As PDB files are missing information like connectivity, atom typing, etc., Rosetta also requires a “params” file for each residue type, which specifies how the atoms are bonded, which dihedrals are rotatable, what atom types to use for each atom, how to build missing atoms, etc. (This is what the mol2 file is used for – for generating the Rosetta params file. Once you have the params file, you no longer need the mol2 file.) Params files for standard aas and a number of others are available in the database, and only have to be provided explicitly if they don’t already exist.
The params file doesn’t include all the information for the force field parameters – it only contains things like atom types and partial charges. The information about how to convert a Rosetta atom type into LJ potentials, etc. is contained in additional files in the database (under rosetta_database/chemical/atom_type_sets). All atoms of the same type share the same LJ settings, the same Lazaridis-Karplus solvation parameters, etc. For the vast majority of cases, parametrization of new residue types proceeds by borrowing atom types (and thus parameters) from other protein atom types.
For the most part this works, as Rosetta puts much less dependance on accurate atom type parameters than typical MM programs. Almost all Rosetta protocols work with fixed bond lengths and angles, so associated parametrization can be ignored. For standard amino acids, even torsions can be ignored, as those effects are captured by using rotamer libraries and statistical potentials. For non-conventional amino acids, there is additional molecular mechanics potentials to compensate for the lack of that information, but those parameters are typically taken wholesale from existing CHARMM atom types, and the only thing a user needs to do is make sure the correct MM atom type is placed in the params file.
So typically, you can reuse existing force field parametrizations, and all you need to provide Rosetta is the PDB for the coordinates, and possibly the params file for the topology/typing information.
February 6, 2012 at 7:34 am #6622Anonymous
Actually, the frcmod modifies the info provided by the mol2 ff (in my procedure for amber parameterization the mol2 file also contains all ff parameters, such as bond force constants, etc).
Could you please indicate where to find the list of atom types for Rosetta?
I would appreciate very much a clarification about the partial charges. How should they be best derived for Rosetta? As everyone knows, this is what differentiates most charmm from amber ff. With each, if the partial charges are not of “high quality”, the protein will not be stable on long MD.
That did not fit my need for MD. Not only for the new aa but also (which I did not mention to simplify my question) for the presence of a transition metal ion in the protein. As everyone know, parameterization of the metal complex for for MD is unique to each complex, not transferable (actually, it is common to see such data to be transferred, however the authors then show MD with short trajectories; their metalloprotein would only be stable on long trajectories if the metal complex parameterization is of “high quality”.
In connection with what I wrote just above, are there examples of Rosetta ab initio docking for metalloproteins? Following the simplified protocol you describe, what about the quality of the results?
That said, I must add that I used in the past both autodock/vina and amber’s dock for small_molecule-protein docking, so that I know that the current state of the art poses limits to docking procedures, much more strict limits than to classical MD.
Thanks for your clarifications and any further advice. I used briefly Rosetta for a recent publication and my difficulty do do more with Rosetta was my inability to locate where things (atom types, etc) are located.
February 6, 2012 at 6:50 pm #6624Anonymous
The list (at least for full atom mode) of Rosetta atom types would be listed in the file rosetta_database/chemical/atom_type_sets/fa_standard/atom_properties.txt (These are the types corresponding the entry just after the atom name in the ATOM lines of params files, the one that controls LJ & LK energies.)
The list of MM atom types (for MM torsion terms, etc.) are listed at rosetta_database/chemical/mm_atom_type_sets/fa_standard/mm_atom_properties.txt with the torsional parametrizations listed in mm_torsion_params.txt in the same directory. (These correspond to the third entry on the ATOM lines in params files.)
Regarding charges, on standard protein runs, Rosetta actually doesn’t use the partial charge values. Instead, electrostatics are taken care of by a statistical residue pair interaction term (fa_pair). You would need to turn on the “hack_elec” term for the partial charges to make any difference. (hack_elec is an electrostatics term with a distance dependent dielectric.) Because partial charges aren’t used by default in Rosetta, there hasn’t been the same amount of optimization of them as there has been in typical MM force fields. When you run molfile_to_params.py, there’s a set of default charges that get assigned (taken from amino acid equivalents) if your inputs don’t have charges. Alternatively, you can supply your own partial charges with a mol2 file, and derive them however you want. I believe AM1-BCC charges have been recommended, at least for ligand docking, but I am unaware if there was an extensive investigation, or rather if they are recommended as they are convenient (at least to people with an OpenEye Omega license). Regarding charging noncanonical amino acids, I would highly recommend following whatever Doug Renfrew suggests in the NCAA tutorials/documentations that are floating around.
I unfortunately don’t know how much work has been done with metalloproteins – especially for protein folding or protein-protein docking. There are parameters for a few metal ions in the database, but I don’t know how extensively they’ve been benchmarked.
- You must be logged in to reply to this topic.