By Vikram K. Mulligan, Baker Laboratory (vmullig@uw.edu). Documentation created 13 March 2014; changes checked into master branch 14 March 2014.
The -in:auto_setup_metals flag has been added to make it easy to import a PDB file containing a metalloprotein and to have Rosetta automatically detect coordinate covalent bonds to metal ions and create appropriate constraints.
In general, there are three broad types of task that a user might want to do with a metalloprotein:
By default, Rosetta is able to recognize most of the metal ions commonly found in proteins (Zn, Cu, Fe, Mg, Na, K, Ca, etc.). On import, however, Rosetta knows nothing about the covalent connectivity between the metal ion and surrounding amino acid residues. As the foldtree is set up, the metal is added by a jump, rooted to the first residue. This isn't ideal, since it means that a small change in the backbone conformation anywhere will not pull the metal along with the surrounding residues.
Because Rosetta knows nothing about metal ion covalent geometry by default, the scoring function will consider van der Waals interactions between the metal ion and surrounding side-chains, meaning that Rosetta will think that it is clashing horribly, yielding huge energy values. Relaxing the structure will push all surrounding side-chains away from the metal, and could result in the metal moving away from the rest of the structure. We probably don't want that.
Even worse, the protonation state of histidine residues (which commonly coordinate metal ions) is, by default, set without any knowledge of the metal. This often places hydrogen atoms inside the van der Waals radius of the metal ion.
Some people have created Enzdes-style geometric constraints files for each metalloprotein on which they want to work, but this is time-consuming and tedious, and requires user input that shouldn't be necessary. It also requires that each protocol know how to use an Enzdes-style constraints file, and many do not. Others have used virtual metal atoms, but this means that the scoring function ignores the charge on a metal ion, and creates other problems. Some people have even created new metal-binding residue types that have included the metal, but this creates its own set of problems. Finally, some have just worked with apo-metalloproteins (the metal-free versions of the proteins), which is valid in some cases, but is not a generally-applicable strategy.
The -in:auto_setup_metals flag has been added to handle import of metalloproteins from PDB files automatically. This flag ensures the following:
Three additional flags control the behavior:
Metal-binding residues have the METALBINDING property in their properties list (in the params file). Additionally, metal-binding atoms are specified with the METAL_BINDING_ATOMS ... line (also in the params file). Meanwhile, metal ions have the METAL property in their properties list. Note: metal ions must have the metal atom as atom 1.
Absolutely. The noncanonical amino acid (2,2'-bipyridin-5yl)alanine (BPY) has been added to the database, and can serve as a demonstration case.
Explicit CONECT records should now be written out by default to the PDB file. You can use these to confirm that there are bonds between the metal-binding atoms and the metal. Bonds to the metal ion will be visible when the PDB output from Rosetta is loaded in PyMOL.
You can also force the dumping of all CONECT records (not just the bonds to noncanonical entities like metal centres) with the -write_all_connect_info flag.
As of 13 May 2014, it does. One caveat is that constraint weights must be turned on explicitly in the scorefunction used in order for metal constraints to work. Additionally, any mover that clears constraints will clear the metal constraints.
UPDATE 25 April 2017: The new SetupMetalsMover provides the same functionality as the flag in mover form (constraint weights must still be explicitly set in the score function). The constraints_only option allows users to add constraints back without setting up covalent bonds; this can be useful i.e. after calling a mover that clears constraints.
Short answer: Yes, probably (as of April 2018) Long Answer: If your metalbinding geometry is through backbone atoms, there shouldn't be much of a concern, assuming you remember to enable the metalbinding_constraint term in your centroid scorefunctions. (It will not be automatically enabled for you.) If the coordination is through sidechain atoms, there are a few caveats. As protein sidechain atoms are not normally present during centroid mode, there's a difficulty in translating the covalent bonds and the constraints into standard centroid mode residues.
Rosetta gets around this by creating a special united-atom residue type, where all the sidechain atoms are explicitly represented. There's two potential issues with this approach. The first is that, because it doesn't have the CEN atom, this special residue won't be scored in centroid mode like a standard protein residue. The other is due to sampling limitations. Because most centroid mode protocols don't consider sidechain sampling, the sidechain conformation of metalbinding residues will effectively be locked in their starting position. This might not be an issue if you're not sampling in the immediate neighborhood of the residue (e.g. if you're doing loop remodeling in another part of the protein), but if you're doing backbone remodeling in the vicinity of the metalbinding residue, you may be unfairly rejecting acceptable conformations due to the immobility of the residue sidechain.
Note this is only if you read in the pose as full atom, apply the metalbinding setup, and then later convert to centroid (e.g. during a loop remodeling segment of the protocol). If you directly read the structure in as a centroid mode pose (e.g. with the -in:file:centroid flag), Rosetta will never have the sidechain atoms to appropriately set up the bonds to the metal and constraints in the first place.
Can you ask that in the form of a question?
Good question. Utility functions are located in src/core/util/metalloproteins_util.cc. (Functions in this file duplicate some of the functionality in src/protocols/toolbox/match_enzdez_util/ with some modifications; in the future, this should probably be consolidated to avoid code duplication.) The is_metal() and is_metalbinding() methods have both been added to both the core::chemical::ResidueType and core::conformation::Residue classes, letting you query whether a residue is a metal ion or a metal-binding residue. For metal-binding residues, the get_metal_binding_atoms() method in ResidueType and Residue provides a list of indices of metal-binding atoms.