Inquiry About Magnesium Ion Handling in rDock

[merveyuce]

Hi,

I am currently working on a project involving rDock for docking studies of RNA targets. I have encountered an issue related to the handling of magnesium ions in the receptor .mol2 file. Specifically, I am receiving the following warning in the cavity.log file when running rbcavity:

RbtMOL2FileSource: INFO Attempting to identify element by 1st 2 chars of FFType string: Mg
RbtMOL2FileSource: INFO Atomic number = 12
RbtMOL2FileSource: WARNING Undefined Tripos type for A:MG_1601:MG

From the log, I understand that rDock recognizes the atomic number of magnesium (12) but does not map the Tripos atom type (Mg) correctly. I have verified the that the .mol2 file is properly formatted, with the Tripos atom type set to Mg as follows:

87766 MG 75.9266 33.1932 16.3591 Mg 3917 MG1601 2.0000
87767 MG 92.9448 27.0208 -2.6341 Mg 3918 MG1602 2.0000
87768 MG 161.6042 36.0729 18.0991 Mg 3919 MG1603 2.0000
87769 MG 83.1210 -3.5749 60.4090 Mg 3920 MG1604 2.0000

I think there may be additional steps required to fully register magnesium ions in rDock's internal atom type handling. Additionally, I would like to ask whether this warning affects the accuracy of the docking results. Could you kindly provide any advice or insights on how to resolve this issue?

[ggutierrez-sunbright]

Hi,

I took a look at the code, and the short answer is there's no problem with that, and those warnings are safe to ignore.

The 'problem' comes from the limited atom type enumeration in rDock (RbtTriposAtomType).
While parsing the atom information, it checks if the atom name is in that enum, but Mg is not. When this happens, there's an extra check to get the atomic number from atom types defined at RbtElements.dat, and later on, properties like mass or atomic radius are read from the same file based on the atomic number, and not the atom type or name.
Atomic charge is read directly from the input MOL2 file, so everything's okay.

I've created an issue to track this, but I don't expect to work on it in the short term, as there are other initiatives already in progress and there's nothing 'broken' in this case.

Thanks for using rDock,

Guillermo