计算化学公社

标题: 请教过渡金属配合物smiles如何生成合适初猜结构 [打印本页]

作者
Author:
Jiang127127    时间: 2025-12-28 22:42
标题: 请教过渡金属配合物smiles如何生成合适初猜结构
本帖最后由 Jiang127127 于 2025-12-29 09:35 编辑

对于图片所示的NHC配体与CuCl配位的催化剂
(, 下载次数 Times of downloads: 0)
用RDkit生成的smiles为Cc1cc(C)c(N2CCN(c3c(C)cc(C)cc3C)[C]2->[Cu][Cl])c(C)c1
smiles先转化成mol,再通过mol生成构象,在查阅RDkit手册后用手册中的方法
m3 = Chem.AddHs(m2)
params = AllChem.ETKDGv3()
params.randomSeed = 0xf00d # optional random seed for reproducibility
AllChem.EmbedMolecule(m3, params)
生成3D构象,并转化为xyz文件,但是生成的初猜结构并不合适: (, 下载次数 Times of downloads: 2)
(, 下载次数 Times of downloads: 0)
请问各位老师,应该怎么通过smiles去生成一个合理的过渡金属配合物xyz文件呀?

作者
Author:
Uus/pMeC6H4-/キ    时间: 2025-12-28 23:09
是什么算法生成的NHC过渡金属配合物的smiles字符串,以及RDKit的ETKDGv3()这个算法确认能处理此类情形的3D原子坐标生成么?

如果不是一定要经过smiles字符串做什么化学信息学处理的话,获取以及修饰过渡金属配合物结构还有别的方式,最保险的是直接找文献里已经优化过的相似结构(例如我总结过的几个数据集),稍微简单一点的用GaussView等直接画也行。
作者
Author:
Jiang127127    时间: 2025-12-29 08:44
Uus/pMeC6H4-/キ 发表于 2025-12-28 23:09
是什么算法生成的NHC过渡金属配合物的smiles字符串,以及RDKit的ETKDGv3()这个算法确认能处理此类情形的3D ...

谢谢回复!
smiles是通过chemdraw先画分子结构,生成smiles,再通过RDkit:
mol = Chem.MolFromSmiles
smiles = Chem.MolToSmiles
规范化smiles。
作者
Author:
wxyhgk    时间: 2025-12-29 08:51
SMILES 本身就没有 3D 的信息,你拿 SMILES 生成 3D 结构本身就是不可行的。

当然有部分深度学习模型可以做到,不过泛化能力极差,都是论文好看,工业上几乎不可用。
作者
Author:
Uus/pMeC6H4-/キ    时间: 2025-12-29 09:11
Jiang127127 发表于 2025-12-29 08:44
谢谢回复!
smiles是通过chemdraw先画分子结构,生成smiles,再通过RDkit:
mol = Chem.MolFromSmiles

平时有ChemDraw的用户不是画完键线式直接拿Chem3D生成三维结构了么,何故绕道折腾RDkit呢,是试过发现完全不对(不是只有个别键长键角二面角得调整的情形)么?

我不知道这个“规范化smiles”的标准从何而来,像->表示金属配位键的语法无论是目前维基百科的介绍还是OpenBabel使用的标准都没有采纳。结构式转3D原子坐标真的没必要倒腾SMILES。
作者
Author:
Jiang127127    时间: 2025-12-29 09:36
wxyhgk 发表于 2025-12-29 08:51
SMILES 本身就没有 3D 的信息,你拿 SMILES 生成 3D 结构本身就是不可行的。

当然有部分深度学习模型可 ...

谢谢回复!
我之前没有补充,是smiles先转化成mol,再通过mol生成构象这样的
作者
Author:
wxyhgk    时间: 2025-12-29 09:42
Jiang127127 发表于 2025-12-29 09:36
谢谢回复!
我之前没有补充,是smiles先转化成mol,再通过mol生成构象这样的

没什么区别都一样的,SMILES 本身没有 3D 构型,你怎么转都一样
作者
Author:
Jiang127127    时间: 2025-12-29 09:46
Uus/pMeC6H4-/キ 发表于 2025-12-29 09:11
平时有ChemDraw的用户不是画完键线式直接拿Chem3D生成三维结构了么,何故绕道折腾RDkit呢,是试过发现完 ...

谢谢指导!
“规范化”是我自己的理解,基于RDkit手册的这一部分:
(, 下载次数 Times of downloads: 1)
我还没有尝试chem3D,谢谢老师建议,因为阅读文献发现作者是通过RDkit生成的3D构象,也想要通过这个来生成xyz文件
作者
Author:
sobereva    时间: 2025-12-29 11:55
如果只有这么一个分子要算,而不是打算批量自动算一大批配合物,弄SMILES字符串相关的纯粹是瞎折腾。直接根据结构化学、配位化学常识在gview里手动画初始结构就完了
作者
Author:
wzkchem5    时间: 2025-12-29 13:06
只是键长不合适,其他没有硬伤的话,产生完构象做一个GFN2-xTB预优化就行了
作者
Author:
Hugo_314cat    时间: 2025-12-29 15:48
SMILES对于金属配合物本身就是有重大缺陷的,若没有绝对必要,我个人极不推荐使用SMILES来描述金属体系。
作者
Author:
Jiang127127    时间: 2025-12-29 22:05
wzkchem5 发表于 2025-12-29 13:06
只是键长不合适,其他没有硬伤的话,产生完构象做一个GFN2-xTB预优化就行了

谢谢老师的指导!按照您的方法问题解决啦,想请教您:我尝试了xtb三种优化方法,gfnff就只是让CuCl键长合理了,但构象并不合理,gfn1/2优化后整个构象就合理了,请问是因为力场方法不能很好的描述配位键体系吗?请问老师我只想得到一个合理的初始构象,后面会进行进一步精细优化,请问用gfn1是不是就可以了呀?
作者
Author:
风起~    时间: 2025-12-30 09:08
10.1038/s41467-023-38169-2
专门搞这个的
作者
Author:
Uus/pMeC6H4-/キ    时间: 2025-12-30 09:43
风起~ 发表于 2025-12-30 09:08
10.1038/s41467-023-38169-2
专门搞这个的

我觉得LANL的这个工作和上面讨论的问题不完全一样,一个是从https://github.com/lanl/Architector的Input dictionary structure and recommendations来看输入文件的信息显然比一个SMILES字符串多很多,再一个原文介绍的流程也已经包含了SMILES转立体结构与GFN2-xTB优化排序的步骤:
First, we initialize chemically-meaningful ligand geometries from the SMILES strings using the Openbabel[42] package, which are then relaxed with either MMFF94[43] or UFF[44].
With different ligand conformations at multiple sites at the metal surface, rapid methods for ranking conformations and reducing numbers of structures breaking chemical sanity are needed for complex assembly. By default we use GFN2-xTB[31] to select FF-relaxed ligand geometries by placing each ligand conformer on the complex and evaluating the total energy to select low-total-energy geometries for each ligand in order from highest to lowest denticity.
实际上OpenBabel的SMILES转3D结构功能也依赖于查询某rigid-fragments.txt文件中预置的三维坐标来转换部分片段,找不到的话也会报错而无法转换。
作者
Author:
wzkchem5    时间: 2025-12-30 11:10
Jiang127127 发表于 2025-12-29 22:05
谢谢老师的指导!按照您的方法问题解决啦,想请教您:我尝试了xtb三种优化方法,gfnff就只是让CuCl键长合 ...

可以。如果要求构象再合理一些,可以用GFN1等方法跑一个简短的退火




欢迎光临 计算化学公社 (http://bbs.keinsci.com/) Powered by Discuz! X3.3