rdkit cannot load some mol2 files

[guaguabujianle]

rdkit cannot load some mol2 files

[sc8668]

Convert the mol2 files into sdf files with some external tools (e.g., convert.py in OpenEye), and then load them into the RDkit using "Chem.MolFromMolFile".

[guaguabujianle]

Thank you for your reply. I have other following questions. First, I saw you uploaded the processed graphs at https://zenodo.org/record/6859325#.Y6KpS3ZBxD-. I found that each data point is stored in a heterogeneous graph object. I guess I should convert it into two separate protein and ligand graphs before feeding it to RTMScore. Alternatively, I can also modify the model to make it possible to process heterogeneous graphs. Am I right? Second, the heterogeneous graph contains three types of distance (cadist, cedist, and mindist). Is mindist equal to the result returned by the function “compute_euclidean_distances_matrix” at model2.py? Do these three types of distance lead to similar performance? Third, do the two auxiliary tasks matter? Do you test the model performance by removing the two auxiliary tasks? To my understanding, the model is just trained to recover the information already included in the input features for the auxiliary tasks. I am looking forward to your reply. Thank you.

[sc8668]

1. Perhaps what you see is the graphs for our previous version. In our published version (Version 2 in the same link), the protein and ligand graphs are seperately stored.
2. "mindist" is used as the final indicator to represent the distance for each residue-atom pair in our final version. Yes, it is returned by "compute_euclidean_distances_matrix" function. "mindist" performs significantly better than the other two indicators, so we finally use it.
3. These two auxiliary tasks are just for training and useless for predictions. Yes, I think what you guess is true, i.e., they are just used to recover the information already included in the input features. However, it should be noted that the decline of MDN loss may in turn lead to the change of the atom/bond types of the ligand, and the inclusion of these two terms can guarantee the reasonability of the ligand to some extents. Of course we have't tested the performance with the removing of these two tasks, but at least the inclusion of them is harmless. We just inherit these two terms from DeepDock.

[guaguabujianle]

Thank you for your reply. I might have the following question. To my understanding, RTMScore is trained to predict a Gaussian-like distribution where mu is supposed to be at a position close to the true distance (i.e., y in the source code). However, when I check the prediction of the trained RTMScore I found that the predicted mu is far away from the true distance y. Is that normal, or perhaps I misunderstood the algorithm?

[sc8668]

sigma and mu are all a group of parameters to determine the distribution of the distance, and the final distribution of a specific residue-atom pair shall be the mixtures of multiple Gaussians. Hence there shall be no relation between a single mu and the correponding y. It should be noticed that mu and y have different dimentions.
Hence I think perhaps you misunderstand the algorithm. To better understand the algorthm, perhaps you can refer to the original paper of DeepDock.

[guaguabujianle]

Thank you very much for your reply. I tried to apply for a license for OpenEye, but I haven’t received any feedback yet. Could you please upload the processed graphs or converted sdf files for CASF2016 decoys_docking set?

[sc8668]

The following are the scores of the poses in CASF-2016 docking set predicted by our models, and I think they are enough to show the performance of our methodology.
rtmscore1_casf2016_docking.tar.gz

rtmscore2_casf2016_docking.tar.gz
rtmscore3_casf2016_docking.tar.gz