Dear Sir or Madam,
I have being tried to dock a ligand to the metal ion of an enzyme. Unfortunately, despite all efforts, the Rosetta (coupled_moves script) doesn't recognize the connection between negatively charged ligand's Nitrogen and Zinc (II) ion and assign two Hydrogens to that Nitrogen atom instead of desired one Hydrogen and the last spend valence for the Zinc ion. I have tried to write down both a direct bond (BOND_TYPE) withing PDB, MOL and .params files between these foregoing atoms as well as CONNECT between them.
Even more, I have written down the flags for metalloproteins.
Here there is a script which I execute:
~/rosetta_src_2020.08.61146_bundle/main/source/bin/coupled_moves.default.linuxgccrelease -s protein_with_ligand.pdb -resfile 4ww6.res -parser::protocol Dock_coupledmoves.xml -coupled_moves::backbone_mover backrub -coupled_moves::ligand_mode true -number_ligands 1 -ligand_weight 1.0 -in::auto_setup_metals true -in::metals_detection_LJ_multiplier 1.5 -in::metals_detection_LJ_multiplier 1.0 -in::metals_distance_constraint_multiplier 1.0 -extra_res_fa eza_nh.params -mc_kt 0.6 -boltzmann_kt 0.6 -packing::no_optH false -nstruct 2 -ntrials 500 -save_sequences true -save_structures true > Output_CM.txt
Would anyone here be kind to explain me how to write down the CONNECT records in params file in a proper way, which set up the connection between two desired atoms, please?
I attach both .params files (with BOND_TYPE and CONNECT records, respectively) to this post.
I will be highly appreciated for your response, and I am looking forward to your response.
Rosetta currently doesn't have a great score function parameterization of metal ion interactions. The support it has is focused mainly on preserving already existing interactions, rather than discovering potentially new interactions.
What the `-in::auto_setup_metals true` option does is enable code which will automatically make covalent connections from the metal ion to likely metal-binding atoms. It will then also add restraints to the current ion/coordinated atom geometry. But note this is set up to simply preserve an existing (ideal) geometry which is coming from the input structure. It won't really work with a ligand docking protocol where you're attempting to find a position of the ligand which will form (new) coordinating bonds to the metal ion.
Adding a connection point in the params file will suffer similar issues. In order for Rosetta to actually use the connect in the params file, it needs to be explicitly told where that connect should be attached to. As such, (for the without Zn case) you'll need to have a free connection slot on the metal ion, and then manually tell Rosetta that the connect on the ligand should be attached to the connect on the metal ion. If you put the Zn on the ligand side, you'll have similar sorts of issues if it's also coordinated to protein residues.
So Rosetta, as it's currently implemented, isn't really set up to do well by just applying ligand docking as a black box to a metal ion containing protein. To use Rosetta successfully, you'll need to go into more detail about what your problem is, what you're trying to achieve, and what pre-existing information you have regarding the results you're looking for. (e.g. do you know which atoms are bonded to the metal ion? The geometry? How much sampling of that do you need? How does that konck-on to the restrictions on how you're sampling the rest of the ligand flexibility?))
Thank you very much for response.
I know exactly which atoms are bonded to the Zinc ion: 1) Ligand's negatively charged sulfonamide Nitrogen 2) Nitrogens from imidazole rings on three Zn-coordinating Histidines and they are taken into account by 'metal' flags, unlike the ligand atom.
As you can see from the updated eza_nh.params file (without Zn), attached to this comment, that atom is specified by the lines:
ICOOR_INTERNAL CONN1 -118.358802 63.892121 1.957637 N1 S1 C1
ICOOR_INTERNAL ZN -118.358802 63.892121 1.957637 N1 S1 CONN1
I copied the data regarding that line from .params file with Zn: I took the PDB ligand file with Zn and generated step by step the .params file and got the necessary data for ICOOR records.
I have already written down the connection of C-terminal Zinc (II) ion with Nitrogen atom from a docked ligand in both params file and XML-protocol file (by mover DeclareBond):
<AtomTree name="AtomTree" docking_ft="true" />
<DeclareBond name="DeclareBond" atom1="ZN" atom2="N1" res1="258" res2="259" />
<CoupledMovesProtocol name="coupled_moves" task_operations="resfile" />
And I met with two problems:
1) Durign Coupled_Moves performance with involvement of original (attached to this comment) params file it provides such an error:
[ ERROR ] UtilityExitException
ERROR: pdb_EZL doesnt have connection at N1
I tried to write down the ZN-N1 connection by accomplishing the CONNECT line for every connection as it is recommended by the following link https://www.rosettacommons.org/docs/latest/scripting_documentation/Roset... and, subsequently, come to the next error:
2) When I add the following lines to the already existing lines:
ICOOR_INTERNAL CONN1 -57.697293 71.529171 1.619809 S1 C1 N2
ICOOR_INTERNAL N1 -57.697293 71.529171 1.619809 S1 C1 CONN1
I get another error, regarded to "a circular ICOOR dependence":
[ ERROR ] UtilityExitException
ERROR: Unable to assign ideal coordinates for residue type eza
Would you be kind to explain what does mean "circular ICOOR dependence", please? I haven't found any information or literature about this circular ICOOR dependence. And how to set up connection for atom N1, because I didn't find any example of setting up the connection record (CONN#) on ICOOR section for non-virtual atom, please? Or there is another way to set up connection for N1 atom without writing down the additional CONN data in params file?
On top of that, I would like to get an example of .params file, where some atom is successfully connected to some enzyme ion and isn't excessively protonated (or detailed guide, how to do it).
Many thanks in advance.
Many thanks in advance.
I have parameterized a ligand (LIG) that coordinates a Zn2+ in a Zn-binding protein. Then used these as inputs for CoupledMoves which successfully rotates and translates both LIG and ZN independently.
This is how I prepare my LIG:
* In a previous step, we saved individual ligand pdbs named `LIG.pdb` using pymol commands.
* Convert `pdb` to `mol2`: `obabel -i pdb LIG.pdb -o mol2 -O LIG.mol2`
* Attach missing hydrogens: `obabel -i mol2 LIG.mol2 -o mol2 -O LIG_H.mol2 -p 7.0`
* It attaches two hydrogens to the Nitrogen that coordinates Zinc, but we know that Nitrogen should have only 1 hydrogen so it can have two electrons for -2 charges to bind Zn2+. Manually open mol2 file in PyMOL, delete extra hydrogen, and `save LIG_Hminus.pdb`. Convert `pdb` to `mol2`: `obabel -i pdb LIG_Hminus.pdb -o mol2 -O LIG_Hminus.mol2`
* Generate standard params using the rosetta utility molfile to params script
* Text edit to place the new params pdb ligand into your protein file in place of the original lig
Note I didn't do anything to the ZN, just leave it in PDB as it comes from RCSB.
In my simulations the LIG and ZN have a very negative (favorable) fa_elec term indicating they are interacting electrostatically with each other.
Hope this helps
Dear Dr. Amanda Loshbaugh,
I am sincerely grateful for such great and detailed explanation. The properly prepared ligand docks with metalloprotein in a proper way so far.
Would you be kind to tell me about one bug/feature of nCoupled_Moves running, if there is any opportunity, please?
This concern consists in that, what the Coupled_Moves workout is slowing down throughout the structure generation. For example, the time of generation of the last structure can exceed tenfold the same time for the first structure.
Nevertheless, I am highly appreciated for your response.
Awesome, glad to hear that worked for you.
I think I've noticed the slow down but unfortunately I don't have a solution at this time and I am not actively developing the app at this time.
For mutating 20-30 positions, I found nstruct 200 to 400 was the right amount to generate. You can probably get away with 200.
Please let us know if there's anything else we can help with.
Dear Dr. Amanda Loshbaugh,
Many thanks for your reply.
The ordinary CoupledMoves procedure generates 5 files for every "nstruct" output - FASTA, stats and three pdb files: ordinary one, the second with suffix "low" and the last one - with suffix "last". These three PDB files are ofter similar structurally and energetically.
So, I would like to find whether can I write down any flag to command line or statement to XML-protocol, which allows to omit the generation of "low" and "last" PDB files (only generates ordinary PDB) in order to speed up the structure's generation? Does the WriteFiltersToPose mover or BuriedUnsatHbonds filter influence to that PDB output? May you or anyone of your colleagues provide such an answer, please?
I have found out that the are several statements at CoupledMovesProtocol.cc file (from ~/Rosetta/main/source/src/protocols/coupled_moves/ directory), these may be responsible for outputting so many PDB structures. I would suppose that the statement on lines 472-496, as well as "*pose_copy" variable(?) are underlied of such CM behaviour. I tried to disable these statements, but it didn't solve the problem. Would you tell me if it is possibe to disable these option within CoupledMovesProtocol.cc file and if yes - how can I do it, please?
By the way, the ordinary PDB output wouldn't be supposed to be the last accepted pose as the "last" PDB file with the lowest score as the both ordinary and "low" PDB files?
I will be sincerely grateful for your response and I am looking forward to it.
I wish I knew about those extra files. I've tried to resolve that as well when I was refactoring the code and couldn't figure out where they came from and made the decision it wasn't worth the time I was spending. Let me know if you resolve it.
I always use the 'last' file for analysis if i need a PDB, but also imporant if you're doing design is the mutation frequency data in the fasta file output.