环境安装
环境安装
这一部分内容主要集中在torch的cuda和torch_geometric等相关软件的匹配问题。
查看英伟达驱动版本和查看cuda版本：
nvidia -smi
nvcc -V
其余相关安装包的版本设计dgl-cuda的问题，需要根据自己的cuda安装，没必要完全与readme中保持一致，若后续出现API迁移等问题，则再反过头来考虑是否是相关软件包版本不匹配的问题。
这里附上所需的软件网站：
https://pytorch.org/
https://www.dgl.ai/
https://pytorch-geometric.readthedocs.io/en/latest/notes/installation.html
根据网址所提供的内容和计算机所需的cuda配置即可。
调试与所遇到的问题
首先根据所需要的参数，在调试模式中需要运行参数。具体配置过程如下：
RUN ------> Edit Configurations ----------> Parameters
将运行参数复制即可
参考readme，运行参数如下所示：
所需相关args如下所示：
inargs在上面所定义的Input函数相关，Input函数也是一个传参函数，传入的参数与我们之前conf里面设置的一致。只是这里使用了一个定义的函数去生成这个对象。
查看inargs
可以看到与我们之前conf里面的参数是一致的。这里的inargs.atom与inargs.res均为False故后面的两个if不需要考虑。
从这一部分看，是将参数传入一个叫scoring定义的函数中，scoring在之前的代码中有定义。可以直接跳转查看。
通过DB我们可以看到是这部分首先出现了问题，VSDataset这部分内容是一个外部导入的内容，通过跳转和逐行分析。
这里要提到120行左右。
这里的self.pocketdir原本为None值，这里使用了一个tempfile.mkdtemp（）创建了一个临时文件夹，临时文件夹在之后会消失。Linux系统下会创建于根目录，这里可以运之后查看其路径。
这里的跳转信息extrac_pocket是关键的报错信息。
这里的报错信息经过验证发现是openbabel的环境问题，openbabel如果不加入环境中， 将无法顺利运行，python 版的openbabel在网络上也研究甚少。经过研究发现如下解决办法。
在调整整体系统环境（pre文件）和用户环境（export）都无效的情况下，最终使用os成功解决问题，在使用openbabel之前，通过本地文件的路径导入所需的环境。顺利解决问题，所有代码成功调试，接下来对输出进行分析。
输出结果分析
输出结果如图所示。输入的格式可以是PDB格式的蛋白，或者pdb的结合口袋，其输出结果一致。id行所示的id表示输入的1qkt_decoys.sdf文件中所含的每一个标签+id数。具体这部分内容的含义尚不明确。score的值，从代码行来看为preds.cpu().detach().numpy()
这里我们只从模型层utilis文件下来看score是如何得来的。
- 首先是通过模型计算pi，sigma，mu，dist，atom_types，bond_types，bach等值。
这里之前传入的参数pred为True，上述参数通过值可以查看均为tensor。 - 通过自定义函数calculate_probablity()对pi，sigma，mu，dist进行函数操作
可以看出定义的函数包含四个方面，分别是Nromal操作（）这里的Normal是正态分布。log_prob(value)是计算value在定义的正态分布（mean,1）中对应的概率的对数。具体可参考此链接下的计算公式：
https://blog.csdn.net/geter_CS/article/details/90752582
th.log就是torch.log返回其自然对数再进行相加。
最后一步也是求自然对数并求和。
这是输出列表中score值的由来。
原子分数计算输出解析
格式输出如图所示，第一列与之前介绍的内容完全相同。score也与之前的score含义完全一致。
由于这里的参数设置，inargs.atom_contribution的值被设为True。仍然调用scoring函数，但是输出却发生了变化
这里多了一个atom_contribution项。具体的每一个参数项内容可查看：
前面模型的读取和数据的预处理部分与上一节中的代码内容完全相似，只是在做预测的过程中，增添了一部分代码：
这里我们可以看到，输出的值出了preds还多一个at_contrs，model和test_loader的内容是保持不变的，只是增加了两个参数。那么其输出发生的变化如下所示：
pred部分是共有的部分，而下面的
if atom_contribution or res_contribution:
contribs = [prob[batch==i].reshape((bgl.batch_num_nodes()[i], bgp.batch_num_nodes()[i])) for i in range(bgl.batch_size)]
if atom_contribution:
at_contrs.extend([contribs[i].sum(1).cpu().detach().numpy() for i in range(bgl.batch_size)])
if res_contribution:
res_contrs.extend([contribs[i].sum(0).cpu().detach().numpy() for i in range(bgl.batch_size)])
这部分是只有atom 或者 res为True时才会执行，也是原子或者残基计算时需要执行的部分。
核心的计算代码在
contribs = [prob[batch==i].reshape((bgl.batch_num_nodes()[i], bgp.batch_num_nodes()[i])) for i in range(bgl.batch_size)]
at_contrs.extend([contribs[i].sum(1).cpu().detach().numpy() for i in range(bgl.batch_size)])
这两行所示的信息即是介绍了，后续输出列的内容是如何计算而来的
从代码层面来解析，bgl.batch_size在这个example里为61，我们仅以i=0的情况来分析，这里的contribs主要是对prob在每个i上进行reshape操作，然后at_contrs是将reshape中的所有值进行求和后输入进去。这一部分内容与bgl和bgp这两部分的数据内容紧密相关。
输出纵坐标的C0 -C19的含义，通过以下这行代码可得知是如何输出的
atids = ["%s%s"%(a.GetSymbol(),a.GetIdx()) for a in data.ligs[0].GetAtoms()]
其中Rdkit包所包含的API分别表示：
对原子进行遍历：m.GetAtoms()
获取原子索引：GetIdx()
获取原子序号：GetAtomicNum()
获取原子符号：GetSymbol()
获取原子连接数（受H是否隐藏影响）：GetDegree()
获取原子总连接数（与H是否隐藏无关）：GetTotalDegree()
获取原子形式电荷：GetFormalCharge()
获取原子杂化方式：GetHybridization()
获取原子显式化合价：GetExplicitValence()
获取原子隐式化合价：GetImplicitValence()
获取原子总的化合价：GetTotalValence()
更多具体可参考：
https://blog.csdn.net/gongfuxiongmao_/article/details/124862281
data.ligs是之前在lig文件中解析出来的mol文件类型，取其第一个（只取第一个即可），也就是1qkt，C—代表这个mol的原子符号，0-19代表这个C原子的原子索引。
至此，其输出的每个数值均已介绍。
残基分数计算输出解析
残基分数计算输出这部分，代码前半部分与原子几乎完全一致，无非是关闭原子分数通道，打开残基分数通道。反应在代码中就是把一个参数设置为Fales另一个设置为True。这部分内容将不再做赘述。
在这部分代码中唯一的不同就是运行run_……类时的输出。其中这一类的分析与我们之前介绍的大同小异。
这里唯一的不通是contribs[i]在不同维度上的相加。
值的注意的是，rdkit似乎不能直接输出其残基，因此代码选择了一个叫做MDAnalysis的库，MDAnalysis的具体操作可以参考：
https://www.osgeo.cn/mdanalysis/documentation_pages/overview.html
先将对象实例化，返回的值分别是residues.chainIDs，residues.resnames和residues.resids。例如，A_LEU346,表示残基链的ID为A链，残基的名称为LEU，残基的id为346。从值上看，目前有79个，但是为什么输出没有79个，则是在输出时又进行了一轮筛选。
这里近输出整行相加不为0的残基，故输出不是79个，而是79个中相加不为0的个数。
769
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
