Unimol Docking V2 strange result on posebuster set

[simmed00]

I followed the posebuster.ipynb provided in your repo, downloaded the weight file and downloaded the eval_set zip files. However, since the eval_set does not contain pdb file, so I downloaded from the Posebuster repo and move the pdb file into the eval_set folder. I ran everything smoothly, and the notebook end up giving me a RMSD<2A passing rate of something near 0.8.

However, when I export the predicted pose, and run the Posebuster quality check again, the passing rate significantly drops to lower than 0.6, and the passing rate with PB-valid drop below 0.2. I checked some of the prediction, in some part of the molecule, atoms clash together, which is quite surprising.

I wonder if there is any difference in the passing criteria in the Posebuster repo and the passing criteria written in your ipynb? And if there is details I missed in running the ipynb provided in your github?

[hypnopump]

Hi @simmed00 , thanks for your interest in UniMol Docking! Could you provide examples of the clashing atoms you mention? And can you describe more accurately the process you follow to calculate the rmsd? It would be great if your issue can be reproduced to better understand the discrepancy.

[simmed00]

basically I followed the Posebuster way like below: true_file is the GT pose, cond_file is the protein, test_file is the prediction from UniMol 5SAK_predict.zip I attached one of the strange output. true_file = root + '/' + subject + '/' + subject + '_ligand.sdf' cond_file = root + '/' + subject + '/' + subject + '_protein.pdb' test_file = unidock_root + '/' + subject_short + '_predict.sdf' buster = PoseBusters(config="redock") try: df = buster.bust([test_file], true_file, cond_file, full_report=True) print(df) df.to_csv(root + '/' + subject + '/unidock' + '.csv') except Exception as e: print(subject, e)

[simmed00]

Thank you for your prompt reply. I ran the posebuster_demo notebook, and the final result is: results length: 428 RMSD < 0.5 : 0.08878504672897196 RMSD < 1.0 : 0.4696261682242991 RMSD < 1.5 : 0.6985981308411215 RMSD < 2.0 : 0.7780373831775701 RMSD < 3.0 : 0.866822429906542 RMSD < 5.0 : 0.9299065420560748 avg RMSD : 1.716739050074667

---

results length: 428 RMSD < 0.5 : 0.08878504672897196 RMSD < 1.0 : 0.4766355140186916 RMSD < 1.5 : 0.7032710280373832 RMSD < 2.0 : 0.7850467289719626 RMSD < 3.0 : 0.8738317757009346 RMSD < 5.0 : 0.9369158878504673 avg RMSD : 1.6454183516713314. So I assume I get it right since it is not very far from the result in your paper.

[hypnopump]

Hi again @simmed00 , your issue was reproduced. The output you shared had indeed some steric clashes, whereas the expected output should not.

• Current behaviour of posebuster_demo.ipynb notebook:
• Expected behaviour:
• Reason: It seems the -steric-clash-fix command mentioned in the README.md was not passed by default in the notebook demo.

This has been fixed in the main branch (please update your code to use it!). Please feel free to close the issue

[simmed00]

Thanks for the fix. I added back the -steric-clash-fix command to the inference call, and the results after running the notebook change a little bit, it looks a bit lower than that in the paper, shown as below:

---

results length: 428 RMSD < 0.5 : 0.05841121495327103 RMSD < 1.0 : 0.28738317757009346 RMSD < 1.5 : 0.5560747663551402 RMSD < 2.0 : 0.7126168224299065 RMSD < 3.0 : 0.8387850467289719 RMSD < 5.0 : 0.9065420560747663 avg RMSD : 2.116286272244654

---

results length: 428 RMSD < 0.5 : 0.08878504672897196 RMSD < 1.0 : 0.3621495327102804 RMSD < 1.5 : 0.6261682242990654 RMSD < 2.0 : 0.7476635514018691 RMSD < 3.0 : 0.8457943925233645 RMSD < 5.0 : 0.9112149532710281 avg RMSD : 1.976056631357393

I further downloaded the predicted pose and check. The earlier example of 5SAK is now fixed. I then used the same code in Posebuster to test it. This time, quite often the warning "Can't kekulize mol" appears (100+). The % passing the <2A criteria is 194/428=45%, and the % passing the <2A and PB-valid is only 160/428=37%. There is still some gap between the reported result. Is there any other details I missed when running the docking?