Support for Mg²⁺ with Octahedral Coordination in AutoDock4Zn

[n-vivek]

Hello,
I am working on docking studies using AutoDock4Zn, and my system involves magnesium ion (Mg²⁺) at the active site. Mg²⁺ in my case exhibits octahedral coordination, where:

• It coordinates with two residues (e.g., Glu/Asp),
• Two explicit water molecules, and
• Two ligand atoms during binding.
  Currently, the scripts and force field provided in AutoDock4Zn seem optimized for Zn²⁺ with tetrahedral coordination.

Specifically:
In prepare_gpf4zn.py, the appended non-bonded pair potentials (nbp_r_eps) are tailored for Zn²⁺, with interactions defined for atom types such as OA, SA, and HD interacting with Zn.
My GPF file is being generated with Zn-specific parameters (e.g., nbp_r_eps ... Zn), even though my system uses Mg²⁺.

My Question:
How can I modify the scripts and parameters to handle Mg²⁺ with octahedral coordination geometry?

Steps I’ve Taken:

• Skipped the pseudoatom (TZ) step since Mg²⁺ does not require tetrahedral pseudoatoms.
• Used mk_prepare_receptor.py to prepare the receptor with the Mg²⁺ ion explicitly included.
• Provided the prepared protein PDBQT file directly in prepare_gpf4zn.py.
• Observed that the GPF file includes Zn-specific parameters, which I suspect might lead to inaccuracies for Mg²⁺.

Specific Help Needed:

• How can I replace the Zn-specific non-bonded potentials with those suitable for Mg²⁺?
• Could you provide recommended parameters for Mg²⁺ (e.g., radius, well depth) to define its interactions?

Other Considerations:

• Should I explicitly retain the coordinating water molecules in the receptor preparation?
• Are there any changes required in the docking workflow due to Mg²⁺'s octahedral geometry?

Thank you for your support! I would appreciate guidance on ensuring that Mg²⁺ is modeled accurately in my docking studies.

Best regards,
N Vivek.

[rwxayheee]

Hi @n-vivek

You could follow the AutoDockZn4 paper and derive your own parameters for Mg2+ (and for a specific coordination pattern, like octahedral in your case). Then for the detailed docking procedure, please take a look at the given example on Vina documentation:
https://autodock-vina.readthedocs.io/en/latest/docking_zinc.html
The non-bonded potentials (and other parameters you wish to override) need to be written to the .gpf file so they can be used to compute the map files. Feel free to reach out to us if you need further assistance or have specific questions on anything else.

We would grately appreciate it if you are willing to invest time into parameter derivation and calibration. Before you do that, you could also just try retaining Mg2+ as an ion and see if the coordination can be naturally formed in docking calculations with the current parameters.

Additionally (just my two cents, for what it's worth......): try including Mg2+ and water into the ligand, by dative bonds. To do this, you will need a certain version of Meeko for ligand preparation that is in develop (forlilab/Meeko#273). We have not approved and merged it yet.

This way, the Mg2+ coordination sphere with ligand (and water) is formed before docking calculation. It can be a quick way for conformer generation, but based on the hypothesis that the coordination is correct in the input ligand structure. See a snapshot of retrospective docking I performed on a trial system:

Let us know what you think ^^

[n-vivek]

Hi @rwxayheee ,
Thank you for your detailed response and the helpful suggestions. I appreciate the insights about handling Mg2+.

• I’ll first try retaining Mg2+ as an ion and check if the coordination forms naturally during docking with the current parameters.
• I’ll also explore the option of including Mg2+ and water into the ligand using dative bonds via Meeko as suggested.
• Parallelly, I’ll look into deriving parameters for Mg2+ using the AutoDockZn4 methodology, in case further calibration is needed to address coordination patterns.

I’ll proceed with these approaches and let you know how it goes. If I encounter any specific challenges, I’ll reach out for further guidance.

Thanks again for the support!

Best regards,
N Vivek.