D3pockets log/20251028before

2025-7-4:75.2~/Backup/History_on_Pocket2Druggability是该课题的备份路径。

2025-7-7:等明天讨论的结果

2025-7-8：现在的结果是需要完成的一个管线：

MD数据->fpocket/d3pocket->比较结果，发现其中口袋的特征，统计规律

2025-7-14：有点搁置了，感觉锦添师姐数据应该差不多了，稍微花点时间部署D3pocket & fpocket

尽快提交下。描述一下数据集：目标文件夹，75.2~/jintian/AI-NCI/

dynamicPDB:原始数据，每个体系100ns&1000帧

MISATO:另一个数据集，每个体系10ns&100帧

dynamicPDB_2050710_clean是dynamicPDB处理过的数据

注：每个体系文件中的.dat文件是RMSD的记录文件，注意clean中是参考的原始蛋白结构，MISATO参考的是初始结构。另外MISATO中的体系是带配体的复合物体系，MISATO目录下的apoprotein就是没有配体的了。另外，MISATO的体系存在多链的情况，存在蛋白链的冗余。

复制到 我的Backup/Dataset

2025-7-16:虽然还没cp完，但是可以先部署d3pocket，需要考虑哪台服务器，1）空间足够 2）cpu性能够。不用移植，85.23上面就有，虽然但是这文件组织真的给我整吐了，强迫症犯了。真的好想全部删了重写，哪有这么写代码的，后期维护起来的想想头皮就发麻。算了，算了，这样吧

测试：85.23：/software/D3Pockets_WEB_UCB

conda activate D3pockets

nohup bash D3Pockets_MD_Script.sh &

pid:201156

测试完成，看看啥样。

mad，这都输出了啥啊，样本量不要太大了吧。。

2025-7-17：需要整理下，最终数据的数据的类型，对应说明的问题。

2025-7-21：活人微死，谢谢。真的，这周开始D3pocket的数据分析了。统计个啥呢。基于什么呢，基于形状吗？考虑残基吗？还是啥啊，好问题。先做出一版来吧

2025-7-22:嘿，nc的一天从忘记带电脑充电器开始。虽然但是想一下任务：路径整理到数据库中，后续直接跨服务器操作。先录入数据库。

数据库的建立

R==relation，E==entity

E<-Md_files(filename,filepath,filetype)好像只需要这么一个简单的表就可以了。数据库就命名为Files，还是没有还是，没必要。起名字啥的最讨厌了，FILEs太笼统了，好不容易起了个DataFiles;

有些需要注意的：1）路径 2）更新

接下来就是开始，还好写了log，不然文件组成就要了老命了。根据需求建表。需求的是蛋白pdb文件和轨迹xtc文件。现在还需要稍微转换下：

1）gmx转换

2）python转换（MDanalysis)

我的建议是都来，然后比较下。

现在先用python转换：

/home/databank/gxxu/Backup/Moleculardynamics/4D3pocket_input/shs$ python 2xtc.py -i ../../Source/dynamicPDB_250710_clean/ -o ../ 

修改一下d3pocket的脚本，改成每个对一个。

2025-7-23:部署在75.4，conda，pymol==2.2.0为啥安装不上。哎，其实自己不太想面对，这python的版本太低了。一更新，tmd就有可能要动底层代码。就很难受。为什么啊，为啥是2.x版。要不这样，运行下脚本，然后一个个统计,稍微写了一个D3Pocket3(75.4)

2025-7-24:pdbdynamics已经转换为d3pockets的输入文件了。然后MISATO换分为单链也处理完了,但是脚本是错的。注释一下，4D3pocket_input中MISATO都没有单链的

现在把pdbdynamics的信息录入数据库。后面把MISATO处理完蛋白链冗余后也录入。

2to3 -w D3Pockets_WEB_UCB给升级到了python3了，但是出现了不兼容问题，

bug记录：

d3pocket.py中96行，缩进

drawnetworksinmoregraph.py 200行，括号封闭

356行，输出语句

clusterpkt_resid.py", line 14,废弃函数sys' has no attribute 'setdefaultencoding'.

drawnetworksin1graph.py", line 185,prenode = sorted(confpkt.items(), key=lambda item: item[1], reverse=True)[0][0]

在 Biopython 1.78+ 版本中，SCOPData 模块已被弃用并移除。

protein_letters_3to1 函数已迁移到 Bio.Data.IUPACData 模块。所以修改draw_sitestable.py文件。

现在最大的问题是MISATO，好象处理完了//NOOOO,没有提取，但是都是默认A链。路径：/home/databank/gxxu/Backup/Moleculardynamics/Source/MISATO/MISATO_MD_pdbs_apoprotein_mono，nohup python batch_extract.py --input ../../MISATO_MD_pdbs_apoprotein --output ../ &

您猜怎么着，还是不行。

2025-7-25:为啥，升级到python3，这结果就天差地别了。我再相信一次,怀疑是重构的时候的问题，

bug:

文件: genpktsmvbyres.py

行号: 164

错误内容: raise "error no 1"

文件: ressite_stable.py

行号: 57

错误内容: raise "error!!"

原因: Python 3不再支持直接使用字符串作为异常对象（这是Python 2的特性）

文件: drawnetworksinmoregraph.py

错误类型: ParseError

细节: 在201行20列附近遇到意外的冒号(:)，就是上面括号的问题

文件: format_pocket.py

错误类型: ParseError

细节: 在19行7列附近遇到意外的换行符(\n)

drawnetworksinmoregraph.py", line 355

    print "finsh: ",netinf

   mmd，还得手动来。代码写得稀烂，2to3根本跑不动。开始修bug，

   read_traj_single_frames.py输出问题

   PyPocket_Detect4MPI.py输出问题

   喵的，直接全部修了吧。现在有一版了，还是不行

  2025-7-26：数据准备好了，就看如何升级或者用旧版.又重新开始了

     妥协以下，D3pocket2-对应原来代码，妥协不了一点，pymol都装不了。

     D3pockets对应可能转换后的代码。

2025-7-31:那个问题不是问题

75.4上的测试是2to3，然后手动修改的代码。(D3pocket3..)

2025-8-1:开始改bug，真不如重写

read_traj_single_frams:for id in outrajid:  # ❌ id 是内置函数 id()

一轮修改，先整合到一起了

二轮修改，逻辑重构

三轮修改，bug修改

2025-8-16:85.23上批量处理获取的脚本已经完成在dddc/gxxu/D3*/D3*/D3Pockets_MD_Batch.sh

应该没啥问题，测试pid:75271。另外利用ai检查了detect相关的代码。

2025-8-18：一步步来，现在我们专注于输入输出流，不注重于算法。并且对每个模块进行单项测试测试的路径在75.4/home/dddc/gxxu/D3pockets/test，环境D3pockets

测试命令：python main.py -p ./data/look.pdb -x ./data/md-nowater-every1ns.xtc

今天测试到，pdbfiles=pocket_detector.cluster(output_dir=os.path.join(args.output,'clustered'),cluster_method=args.cluster_method,write=True)

1/29测试通过

差不多可以进行到detect的测试：2/29

开始测试mpi下的detect，测试路径：75.4/home/dddc/gxxu/test/test_2_29

测试命令：mpiexec -n 4 python main.py -p ./data/look.pdb -x ./data/md-nowater-every1ns.xtc 

暂时没通过，在修改分布式问题。仔细分析下来，pocket_detect类并不合理。不如单纯的函数实现...

函数级隔离过不去了。

391197，测试一下会不会结束。感觉不会，这样吧，我们先跳过并行部分，专注于文件流的处理。明天继续2/29测试。

2025-8-19:2/29测试通过。并行化以及detect过程的优化后面再说，现在开始3/29

2025-8-20:3/29测试通过，大差不差，series.py好像没啥用。开始4/29测试:getpits，测试通过。

开始5/29测试：densityball_clu.py，测试通过。开始6/29测试：genpml.py。开始7/29测试：genstable_pml完成测试。开始8/29测试。

2025-8-21:8/29测试通过。开始9/29测试：summary,测试通过。下一个测试：10/29：genpocketsmvpml。测试通过。11/29：gennetwork1input测试通过。下一个12/29：drawnetwork

2025-8-22:草了，不是代码的问题。准确来说不是我修改后代码的问题。是tmd他默认第一个就是一个size=1的节点。问题出在前面没排序。12/29测试通过。13/29：gennetworksinput测试通过。

结果和原来的有细微的差别。

上面之前，下面之后。

源自于聚类的结果。

开始14/29测试：drawnetworksinmoregraph.py。之前的报错就出在这里。删了，我们就用默认的。测试通过。开始15/29测试，drawnetworksin1graph.py。测试通过。16/19测试network2mvpml，17/29测试gencontinuity_pse.py通过。18/29测试：getatom,测试通过。

19/20：ressite_stable测试通过。20/29：draw_stable：测试通过。

2025-8-23：21/29测试：gen_colorpktresipml，测试通过。22/29测试：create_sqlite.py，改成mysql的，手动创建这么一个库。ok，75.2 库：pktsatmclu，表：CREATE TABLE IF NOT EXISTS pktsatmTab (

    id INT PRIMARY KEY AUTO_INCREMENT,

    cluid VARCHAR(255) NOT NULL,

    clusize VARCHAR(255) NOT NULL,

    pktatmfile TEXT,

    simm_avg VARCHAR(255) NOT NULL,

    pktatmfiles TEXT NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

    一下内容遗弃了：SQLITE_DBNAME = "pktsatmclu.db"

    SQLITE_TABLE = "pktsatmTab"

    conn=sqlite3.connect(SQLITE_DBNAME)

    cu=conn.cursor()

    create_tb_sql='''CREATE TABLE if not exists pktsatmTab (

                id integer primary key autoincrement,

                cluid TEXT NOT NULL,

                clusize TEXT NOT NULL,

                pktatmfile TEXT ,

                simm_avg TEXT NOT NULL,

                pktatmfiles TEXT NOT NULL

                )'''

    try:

        cu.execute(create_tb_sql)

    except:

        print ("Table exitst")

    cu.close()

    conn.commit()

    conn.close()

    下一个测试：23/29：clusterpkt_resid,测试通过。下一个：24/29：genpktsmvbyres，测试通过。下一个测试25/29：gencommonpktmvpml，测试通过。下一个测试 26/29:drawmat_heatmap

 通过。死了得了。27/29：volume_correlation，测试通过。28/29：matrix2heatmap，测试通过。

 29/29：selectPocketCorrelation,测试通过！！

 2025-8-24：continuity那里用新的pymol打开还是有点问题。总之除了并行，所有测试结束了。接下来是优化，重整化，与新功能开始。现存档一下：75.2/home/databank/gxxu/Backup/History_on_D3pockets_2.0/D3pockets_py3

 pdbdynamic计算中断：3mfd，重启了。

 2025-8-25:开始D3pocket的优化，首先一点是绘图优化。matrix2heatmap用一个函数测试：测试通过。

 2025-8-26:Drawer3D类统一生成Pse文件，跳过pml的生成，pml内容写入log文件。测试路径还是：/home/dddc/gxxu/testpy3_re/test_re_1 测试通过。

 2025-8-27:continuity的pse文件也通过genPse函数，测试路径还是/home/dddc/gxxu/testpy3_re/test_re_1，草了，stability咋还不能用了，stability写错了。现在测试通过了。开始下一轮修改，test_re_2:drawnetworksinmoregraph.py,drawnetworksin1graph.py,drawnetwork.py 主要是优化整合这三个函数。不过首先，我把matrix2heatmap整合到drawer2D中了，没啥问题，但是漏掉了correlation的pse绘制过程，这必须整上，然后再drawnetwork，genCorrelationPse，测试路径：/home/dddc/gxxu/testpy3_re/test_re_2,测试通过。现在开始关于network的draw整合.

 我稍微试一下drawmorenetwork替到drawnetwork的，结果是不是一样的。统一一下输入绘制network的文件的内容格式，第一列都不带路径。问题在于图生成的逻辑tmd统一，现在75.4中是1的生成逻辑，本地是s的生成逻辑。

 2025-8-28:事实证明用s的生成逻辑就可以。然后整合到drawer2d上。drawnetwork*都整合到Drawer2D中了，测试通过，test_re_2结束

 2025-8-29:今天，我么写一个GPU加速pocket_detect的版本，test_re_3先修改pocket_detect中调用的函数，然后再test_re_4中完成CUDA加速版本，混合版本之后再说。算了，哥们懒得优化这些函数来，直接写核函数哪

 策略：编写C++/CUDA核函数 b. 创建Python调用封装 c. 优化数据传递 d. 性能测试

 2025-8-29:对pdbdynamic已经去全部处理完了。1185个

2025-8-31:CUDA并行化，先到这里吧。在另一台电脑上。先处理pdbdynamics的结果，处理脚本在p75.2:~/dbdynamics/analysis,明天在继续分析

2025-9-1：分析的结果出来了，有个问题：为啥pdbid是上万个..

1185pdbid中只有13个成药的蛋白。以下是分析输出记录：

‘’‘从数据库中获取了16503个PDBID(去重前)

去重后剩余15373个唯一PDBID

Analyzing PDBIDs: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1185/1185 [10:03<00:00,  1.96pdbid/s]

处理的PDBID总数: 1185

其中成药蛋白: 13个

非成药蛋白: 1172个’‘’

显然统计量太小，两者没有显著差异

以上都是continuity，以下是stability

现在开始把MISATO_over 用import2mysql导入DataFiles数据库，然后用D3pocket*MD*Batch，处理，输出到/home/databank/gxxu/D3pocket_Result/MISATO

85.23:~/gxxu/D3P~WEB/**/read_traj* .py 增加了帧文件的导入方式，然后修改了批处理过程。

DataFiles增加帧文件表。

有点问题，gene_target中是肿瘤的，我们还是要所有的,所以新建了FDA_approved表。新的结果替换了原来的结果。还是在analysis中，本地是（analysis_drugbank)

新的结果如下：

stability

correlation

2025-9-4：cuda_interface的测试文件：test_cuda_interface.py通过。在test路径下，核函数是test_kernel.cu。我非常想吐槽一下，有时候他能跑，有时候跑不了。就cuda时连时不连。测试路径在test_re_4

2025-9-5:开始PocketMatrix测试，测试路径：test_re_5

2025-9-6：在75.1/gxxu/tmp中编译了一下，cuda_ops_test编译成功，说明核函数没有一点毛病，还是参数传递的问题。没有g++他怎么预编译的呢？现在来确定是哪个参数传递的问题。救命啊，我到底干什么，他怎么就跑起来了。但是可以确定的是cuLaunchKernel传入的params一定是指针。

test_re_5/test_pocket_matrix通过，test_pocket通过。///虽然我不知道代码算法是否有变化

开始test_re_6:集成测试，python main.py，和算法修正，新建了输出路径results用于区分output中的参考输出，预计能控制在4min内

2025-9-7：现在是整合一下新的代码。

2025-9-8：还是先修正detect算法，在testpy3中新建test_ref，将python3（from test_29)d3pockets运行look的测试体系，输出检测过程中的关键变量，

关键变量如下：matrix_B,matrix_S，一边logging，一边存入txt文件。

然后test_re_6先增加了kernel_cache

2025-9-10：目前的修改进程是实现多GPU并行计算的，核函数的编译在CUDAManager初始化后完成，然后存在核函数缓存中。每次launch，只需要指定核函数的名称，然后从缓存中读取指针。

后续的计划是修改pdbfiles的并行化，pdbfiles之间才是并行的，单个pdbfile中的fill、到那啥是数据依赖的。

今天基本实现的多GPU的fill函数架构，但是存在一个死锁的问题（单个GPU负载过剩）需要优化一下，另外就是nohup.out中的错误，本质上还是上下文错误。以上错误修改后，再测试下，就可以修改到pdbfiles上的并行。

2025-9-11：以上错误的解决是通过各个Worker负责各个GPU的数据指针的创建和释放。基本完成，但是有个问题，为什么还会栈溢出呢？？？？还是存在一个GPU死命计算，另外的占有率为0.然后显存还一直在增加，大问题。

2025-9-12：存在问题：fill的矩阵是叠加的，最后不是1-0矩阵，最简单的需要除以GPU数目。发现问题所在了总共有两个PocketMatrix，然后每个都会在每个GPU上分配一遍那些常量，然后现在测试只有B矩阵的fill，然后S矩阵的就释放不出去，一直积累。可以先做个简单的测试，把S矩阵的内容放到return后面。没有死锁了，但是内存还死命的往上涨，妈的到13个G光fill。然后你会发现有些地方内存越界的离谱有些就没事。析构函数正常删除了内存，难道还是核函数加载的缘故？也不对啊，这样，我们先注释掉launch_kernel中的编译内容，看会不会出错。不会出错，但是还是会死锁。。。。

不对啊，注释了，他还是反复初始化核函数缓存啊，主要我还一直找不到反复的逻辑。卧槽了tmd，原来是服务器main代码和本地的代码不同步。破案了，就是代码不同步的缘故。。。。

2025-9-14:统计了成药蛋白和非成药口袋的几何特征（体积和表面积）

/home/databank/gxxu/D3pocket_Result/pdbdynamics/analysis_geo中分析的是以上结果。

analysis_filenum是上上面的结果。

2025-9-15：还是存在x,y,z边界访问问题，总是伴随着只有一个GPU的高占有率，还有两个100的情况？？怎么哪个变量都会越界？？？ijk,xyz，tmd，开六个GPU，也是经常会出现一个或者两个GPU100占有率的情况？我有个好idea：要不把所有设备对应的指针都写入对应worker，然后结束后统一释放，这样就完全隔离开了。隔离开了，还是有问题。用test_fill_kernel测试了一下，参数都是错的。兜兜转转，又回到了传参的问题上。草。

2025-9-16：

重要总结###########################################################

MISATO的冗余问题暂时先不用解决!

D3pockets需要的是新的口袋性质描述

{柔性、结合性、暂时能想到的是这些

最终的输出是：{描述量--->可视化}

另外可以考虑增加一个新的模块：面向配体的分析模块

首要思路：分析结合（有活性的）配体柔性和蛋白口袋的柔性是否有高的亲和性，对应于前面的想到的结合性。

下一个统计任务是分析成药蛋白的内部比较，1.要标记出成药的口袋 2.比较成药口袋和非成药口袋的在stability、continuity和correlation上的性质。统计量越多越好：数量、几何、能量.etc.

###################################################################

测试标量用主机ctypes指针

2025-9-17：有两个选择，一是继续在目前的代码上进行优化，二是重构代码改用pycuda。前一个选择改动最小，后一个改动工作量就很大。再磕一下前面一个选择。你猜怎么着，解决了！不用重构了。这个版本一定要封存：75.4：~/gxxu/testpy3_re/test_re_6，虽然我还是没想明白是不是只有输出访问有问题。

开启新的副本：test_re_7:

2025-9-18: test_re_7,试一下全部pdb的fill过程，矩阵更新的逻辑有问题，现在改成了主从GPU模式，默认采用第一个GPU作为主，存储常量和多GPU共同变量。行不通，不够通用。还是用预先载入的形式，然后想办法汇总多GPU内容吧。他这个值分布我有点不明白，比如3个GPU，最终出来（3，2，1），出现1，说明每个矩阵点还不止操作了一次。但是只要不是3，就是0，3是1。现在修改了，在测试。测试通过

但是现在已经到了代码的最瓶颈了，无法确保fill、surf等函数的前后关系。必须得重构代码以确保后续开发，当然，先从流的角度确认下还有没有将就的可能，暂时想不到。明天还想不到就重构

还有可以优化的空间，常量还是被随着PocketMatrix类被重复释放加载到GPU上。

2025-9-19：应该要重构了，最小的改动是将多GPU分配放到detectpocket函数中，总感觉要重构这个函数。先这样，我们先把两个fill都，测试下来是没啥问题fill，但是后surf就有问题了。仔细一想

每个PocketMatrix都会对worker中的指针操作，相互干扰了。需要重构，真正实现并并串并并。还有个问题就是fill函数还不能用单个GPU，算力不够。为什么只有一个GPU的内存在增加

2025-9-20:我也不知道我干了什么，然后就跑起来了。。。。反正现在surf函数没有一点问题。但是发现stepsize数值异常的大：1065353216 

到substrate函数可以了，现在解决stepsize的问题。原来只是copy_from_device的dtype参数整错了，实际运算还是正确的。解决了。先测试到substrate。

############成药蛋白的成药口袋和未成药口袋的统计分析

策略步骤：

1.成药蛋白[p1,p2,...,pn] n现在是70

2.对pi，对应一个pdbid，转换为uniprotid 

确认晶体结构中是否包含：蛋白结构+药物结构，其中药物结构对应于drugbank中的药物结构。

3.在药物/配体分子生成口袋preal

4.遍历d3pockets的计算结果，计算 rmsd（preal,pj),pj ∈ pi。返回match_results { pj: rmsd}

选取阈值 rmsdupper，将match_results划分为 druggable_pockets（dp)[pm],undruggable_pockets(udp)[po]

5.遍历统计量列表[ volume,surface area,...,],对每个计算不同的量

产生dp_statistics:{ pm: (volume,surface_area,...,)}

udp_statistics:{po:(volume,surface_area,...,)}

6.完成所有成药蛋白的统计量计算，然后分别对每个统计量进行可视化

volume: 用比体积可视化，横坐标是蛋白序号（默认按照pdbid排序），纵坐标是比体积

mean(dp_statistics.volume)/mean(udp_statistics.volume)

surface_area:同上，用比表面积

增加两个统计量：

deepth

hydrophobic

electronic potential

2025-9-22:写analyze_pocket_withinprotein了

2025-9-23：开新测试本，75.1~/gxxu/test_re_8

2025-9-24:区分一个蛋白内的成药口袋和未 成药口袋，就是要明确1）成药口袋的特征 2）特征之间的度量。现在统计用的是距离度量，肯定不准。终于编写完了，命令：

75.2：~/analysis_pocket:

环境：X_X：J,

命令：python analyze_pocket_withinprotein.py --pdbid_dir ../  --output_dir ./results/ --pocket_threshold 10

结果测试下来，只有三个蛋白通过流程，1184-70-3，还是要数据集

但是先总结点经验：最大的问题相似度量如何把获得的口袋定性为成药的口袋和未成药的口袋

然后明天继续测试D3pockets

2025-9-25：到scan_neigh函数都通过了。测试75.1：~gxxu/test_re_8

环境：D3pockets

命令nohup python main.py -o ./results -p ./data/look.pdb -x ./data/md-nowater-every1ns.xtc --gpu_ids 0,1,2 &

开启下一轮Pocket类测试

test_re_9:去除了fill_kernel中的输出，开始测试，测试通过。现在就是Pockets类了。

from_grid核函数dims存在问题，-1030317932，-1034148118，-1035116216，stepsize=0.0000怎么是零啊？

mincoord=[1.00,0.00,0.00],现在问题没了，只是传参位置错了

现在问题是from_grid核函数为什么没有循环，因为每个线程处理一个格点了，就不用用循环了。果然核函数应该面向矩阵。

现在的问题是from_grid处理的grid都是0，2，7，不是10，12，1012等。说明是前面的scan_neigh的问题，至少surf应该没问题，substract总感觉也没问题，感觉label*也没问题。又感觉scan_neigh也没问题。我怀疑是因为只有一个pdb的缘故。所以不如全试一遍，正好看看有没有相互干扰。没有相互干扰，但是全是027吗，是的，说明有个环节错误。就差临门三脚了。

2025-9-26：现在确认一下原D3pockets中的值分布，mmp就是不输出。而且还都是027。会不会有可能是matrix中没有11的缘故。实在是眼瞎了，现在就靠用没有GPU加速的看看结果，有结果了，现在看看谁在犯罪，fill是良民，surf在犯罪，1全变成了-2，无一例外。

2025-9-27：发现一个问题，surf函数应该不处理0，为什么零的数目还改变了呢。破案了，是fill到surf的过程中矩阵变了。换个策略，每个函数最后不向GPU更新指针了。非得经过device_ptr才能赋值给字典吗？？？

我不明白了然后现在还是有漏网之鱼，但是我就是看不出一点区别来，但是现在from_grid没啥问题了，然后就剩cluster_point，add_buffer

2025-9-28:开新本test_re_10，采用rapids的DBSCAN进行聚类，test_re_9完成了到from_grid的，虽然还是不明白为什么surf后的结果还是有差别。

DBSCAN没啥问题了

有问题，现在就剩DBSCAN了，不知道为什么会句柄失效呢，首先各拷贝到GPU的数据无关就是DBSCAN句柄失效了，就。。。修好了

我感觉是cp.cuda.runtime.setDevice(worker.gpu_id)必须要强制设置Device，

最终准基准测试开始：1390.441s，还是23min，但是我觉得还能再压缩。

2025-9-29：最终整合：D3pockets.2.01，先修复了drawnetwork的传参bug，虽然我也不知道为什么之前能顺利跑起来。（记得在75.4上要改成cuda 12.9），需要继续修复surf函数，想一下B矩阵的-2多了，也就是有些0莫名的通过surf的条件，S矩阵-2少了，也就是说有些1没有通过surf的条件。可能的不同点再neighbor的条件和赋值条件，开新本：75.1：test_re_11,不开新75.3

另外，重新修正一下策略:pass

2025-9-30:我现在纠结到底要不要修改了，这结果又很好。记得数据库临时操作要删除

另外产生continuity的绘图过程有错误，在修改

证明目前的结果没问题的两种思路：

1.surf结果的中间计算：保存surf后的B矩阵，导入原子，0，1，-2标记点，对比优化前后的结果

2.根据实际的晶体结构中的配体，确认是否成功预测到了配体结合口袋

-首要问题是argparse需不需要用宏，还是在主接口中实现，应该要避免宏的使用的。很简单的解决了，直接加在主函数接口中。但是环境变量可以用宏。但是要注意的CUDA toolkit在不同服务器上的版本问题。

-然后是输入参数的问题，暂时先那些参数吧

-这一版里需要增加批量处理的功能吗？不行路要一步步走，步子太大容易扯着蛋。

-下一个问题是这一版需不需要实现任务队列？更不行了，这个是2.1版本的事情。

-下一个问题这个版本需要把hiearchy cluster改成GPU版本吗？我觉得需要，但是cuml中没有hierachy cluster的实现呢。不可压缩的时间，没办法了。

-下一个问题要不要写入文件呢？首要问题是不写入文件后续能用吗？？后面生成的pdbfiles，每个都要用PDBparser转换，然后进行下一步的，就看这两者能不能兼容传递了。然后还涉及到clusize.txt文件的问题。clu_size.txt直接logging一下就好了，不用写入文件。但是问题就在于，如果不写入文件，后续的处理就没法进行了。除非不用轨迹文件用帧文件，留给2.02版本。

-不要什么都留给下一个版本，这也不是什么特别麻烦的功能。但是好像提前把轨迹文件转化为帧文件又没必要。综上所述，没必要做那个功能。

2025-10-9：

-detect_pocket就不通过detect_config传参了，省去不必要的内容，本来参数就没很多。

-然后在detect_pocket中添加注释，probe_out=bradius,probe_in=sradius

-现在pocket_detected中的文件命名用pdbfile构造，不用output_dir了。草，还不能这么改。

-2.01版本不想优化了，先到这里吧，修一修绘图，清除一下数据库，然后替换下核函数就行了吧。

-干正活，先修复绘图的bug de continuityPse

整理出D3pockets2.01版本,我发现test_re_11那么多口袋的原因之一可能是因为版本迭代没清除旧的文件，例如pdb0实际上只有一个口袋，然后savepocket的时候，文件命名也弄错了（i+1）而不是i。test_re_11怎么通过的，又出现了一堆错误。好吧，不是啥大问题。然后又回到了continuityPse的修复啦

2025-10-10:总结出2.01版本的时候出现了各种错误，先开新本test_re_12,测试test_re_11的结果。破案了，原来是test_re_11和现在2.01版本结果是一样的，问题是为什么只保留一个口袋？日志里有那么多的点明明。把test_re_10copy到12中，然后确认一下结果,10到11到底发生了什么？

目前看下来，substract出了问题。也没问题啊，反而是原来的代码，为什么substract后还有-2呢？？

但是现在的问题就是都是在一个位置上重复形成口袋,现在怀疑两个原因：1网格小了；2保存过程有错误。行吧，已经能确定不是i+1的锅。问题出在前面,想不到，要不试一下缩短stepsize=0.5,口袋多了，然后再试试step=0.25

2025-10-11:当前的架构其实到头了，需要新一步重构。难办啊，先修其他bug吧，stepsize=1先走通，然后再考虑具体 算法的调整，框架的重构。

首先排除一下这个错误是不是前面算法导致的。

2025-10-12：

好嘛，限定FDA通过审批，只剩下11个了，看来前面的通过审批是不只是FDA。现在能确定是因为targets导入的问题，drugid前面有空格

现在到了41个，缺少的是因为缺少审批信息。

确认下来，的确就这些，其他的都没通过审批。以1mlw为例，

新策略：参考药物结合口袋的动态行为与成药性研究

2025-10-13：注意从pdb库中的chemcomp中获取配体的结构。

2025-10-14：现在又回归到为什么只有一边有口袋，另一边没有口袋了。然后导致了后续的错误，

架构到头了。开新本2.02版本，开始新的架构，这次我决定，先不分类，全部脚本文件写完了，然后开新本整合。不不不，不能另起炉灶，从2.01过来。

继续分析：pass

2025-10-15: 现在这个log专注于D3pockets的框架整合,来自后续开发的要求，需要一个独立的口袋生成逻辑代码。一方面是原来的预测，另一方面基于实际的配体在周围生成口袋。

另外，我觉得CUDAManager需要有一个子进程，始终维持接受，分发汇总的任务

有一个很大的问题就是主进程的结果同步，还是要弄清楚阻塞和同步逻辑。

继续编写新的框架吧。

CudaInterface就比较好听，代替原来的CudaInterface类

现在还有个问题：是启动核函数的时候才加载核函数到GPU上还是预先加载全部核函数

2025-10-16：Kingcrimeson

2025-10-20：还是那个问题，启动核函数的时候才加载核函数到GPU上，还是预先加载全部核函数到GPU上。

预编译compile_kernel只用于生成cubin预编译文件，且.cu和cubin文件同目录，然后初始化cudainterface的时候，检查一下有没有cubin文件，没有则调用compile进行预编译，算了，还是在main函数前面吧。√

增加一个核函数全部加载的开关，不对，全部加载也不在CudaInterface中，而是在GPUWorker中。√

然后增加间断核函数缓存机制（pass，因为核函数占不了多少显存 ）

我总感觉Worker和WorkerThread有点功能上的重复了，不行不行，得重新理清一下思路。

首先，GPU的计算任务肯定要通过cudainterface的示例对象进行提交的，然后现在有一个submit_task函数了。能想到的就是提交{ kernel_name, args, 其他必要的或者不必要的参数}

直接用这个函数提交任务，加入到task_queue中。

任务队列中的任务是如何分发进工作线程的呢？

首先工作线程是依赖于CudaInterface的线程，即主线程。所以只要程序运行就会持续提交任务。

然后CudaInterface和每个工作线程共用一个队列，然后提交任务的函数持续获取队列中的任务，然后提交CUDA计算

靠的是run函数

现在看如何保持同步，然后获取结果。

##我现在最怕的就是同步问题了

2025-10-21:

现在的第一个问题：外部函数-CudaInterface(submit_task)->launchkernel的过程中，参数是怎么变化的。首先参数要拷贝分配到设备内存中，需要对应设备内存的，所以到工作线程上才真正的分配到设备上。前面都是组织核函数参数，也就是说submit_task需要提交的至少是：{核函数名称和参数}

然后工作线程和Worker的功能重叠了，去除CPUWorker，在WorkerThread中增加原功能。

#增加一个原则copy_to_device  中包含内存分配， copy_from_device 中包含内存的释放。就不单独作为方法了，都放在memory_ops.py中的。

2025-10-28:

让我们继续吧，现在的问题是如何返回完成计算的结果，然后现在基本完成了CUDA任务队列的架构了。