FGCNC在社交网络上的实验

2022.09.06

1.总的结果还不错；
2.但是有很多子集的结果出现ACC和F-score很高，但是NMI和ARI很低的情况：
（1）这些子集的特点：
	①真实类别少，只有两个类；
	②样本的真实标签少，只有极少部分的样本具有标签信息；

2022.09.13

1.gplus数据集十分耗时间，且不能一次跑完所有子集；
2.对于其中一些子集，当gcn层维度减少时，聚类效果会得到明显提高，甚至有从0~0.99的情况；
3.可以考虑：参考GMM-VGAE的代码去实现FGCNC的pytorch版本；
4.对于GMM-VGAE的模型，一定先要进行pretraining，然后才可以再进行training；

2022.09.14

1.DFCN的代码中，没有pre_train部分；因此后期需要看一下论文中这块应该怎么实现的。
2.SDCN代码同理，没有pre_train部分；（但是，SDCN的readme中有关于pre_train的说明；）

2022.09.15

1.SDCN生成的pre_train模型不能直接在DFCN中使用，因为其中保存的一些AE相关的参数个数不同；
2.但是DFCN的pre_train模型的生成可以借鉴SDCN的方式；

2022.09.16

1.实验中的一个问题: 在计算acc或者F1时出现错误, 例如Facebook的子集348.npz;原因如下:
(1)代码错误是因为pred的类别数与true的类别数不相等;
(2)实际原因是因为true中的类别数为[0,1,6,11];以此导致了后续的一系列错误;
**(3)后期此处尝试是否可以继续优化;**

2022.09.19

1.在DFCN模型中，pre_train的生成同时需要GAE和IGAE，因为无法顺利地将SDCN的pre_train方式迁移过来；
（1）将此问题成功解决：通过参考SDCN中pre_train的方式，结合GAE和IGAE一起，先写一个pre_DFCN，然后再进行pre_train;
2.在使用k-means对facebook进行聚类时，发现采用邻接矩阵聚类比特征矩阵聚类的结果好很多；

2022.09.20

1.在facebook数据集上，我们模型的结果明显没有DFCN的结果好；
（1）对于DFCN，结果取值来源于acc结果最好时的epoch，因此出现了总共200epoch时，但是在10epoch时就取到最优结果的情况；
（2）对于我们自己的模型，可以借鉴这种结果的取值（但是应该保证起码epoch>10时进行选取最优结果）；
2.在facebook数据集上进行了简单的参数分析，【512，256】，【256，128】，发现GCN网络层的不同也会导致不同的子集结果发生变化；因此后期可以考虑在此处如何调参；

2022.09.21

1.GMM-VGAE在facebook数据集中的1912子集上运行时报错；
（1）原因：在第1个epoch时，GCN卷积中生成的weight参数中存在nan值；
（2）目前尚未找到解决方法；
2.SDCN非常占用内存，尽管是进程数为2时，也无法开启训练；
3.突然想到gae和gcn区别的问题，肯定是有区别的；
（1）之后需要对此处研究，看原论文；
4.GVAE的结果比GAE的结果差一些；
（1）按理说不应该的呀，为何？？？

2020.09.23

1.之后写长论文的时候，有关GAE-based的背景介绍详细介绍时可以参考：
（1）https://blog.csdn.net/qq_39388410/article/details/107895198
2.对于GAE模型，其是一个无监督模型，loss计算是重构损失，acc的计算是重构adj与原始adj之间的交叉熵计算，因此无法从节点聚类的角度去进行求解分析：
（1）对于此问题：没有找到相关的说法，初步想法是在进行embedding时，最后一层的维度设为聚类个数，这样便可以由此得到一个聚类标签，进而达到节点聚类的目的；
3.对于GAE和VGAE模型，运行效率非常高；
4.对于GAE和VGAE模型，两个模型在一个代码文件里，运行时需要在参数中进行设置；
5.DAEGC模型中， pretrain.py文件是进行模型预训练的，daegc.py文件是用来正式训练的；
6.DAEGC模型中，在pre_train时，原始代码中的最大epoch为100， 但是发现20时结果更好，因此将其改为20；

注意：
1.在使用多进程时，如果代码有误的话，程序是不会报错的，而是不运行子进程，直接运行主进程到结束；

2022.09.23

1.对于ARGE和ARVGE莫模型，其实现在一个文件中，运行前选择参数model即可；
2.在tensorflow中，每一个子集跑完之后，都需要将模型的参数重置，不然会显示参数已存在，这是有别于pytorch的；

2022.09.26

1.将算法转移到服务器上运行时，开不了多进程；
（1）并没有找到特别确切的原因；
（2）但是将多进程代码进行改写：apply_async()替换为map()之后，可以运行起来；
（3）具体原因之后还应继续分析；
**（4）找到原因了：
	①使用多进程时，不能将model（甚至是对象）作为参数传入函数中；
	（注意：非多进程时，是可以传入参数列表中的。）
	②对于全局参数，应该在task()函数之前就定义，最好是就放在代码的最开始。
==（5）
①使用apply_async()时，子进程遇到报错不会提示，知道主进程结束；
②使用map()时，子进程遇到报错会提示，主进程也就不会正常运行了；
因此，在进行代码调试时，可以优先考虑使用map()。
（6）还是存在一个效率问题：
	在gplus数据集上的运行时间特变慢，即使是gae这种简单模型，也会花费较大时间；

2022.09.27

1.在服务器上的环境中，需要安装torch_geometric；
2.注意：SDCN这类模型中，在生成pretrain模型时，需要提前生成数据集子集的目录；
（1）save_path存在问题，貌似不可以使用相对路径；
	（可以的，之后发现错因在于保存路径写错了。）
3.即便是在服务器上开启多进程，SDCN仍然很耗费时间（包括在twitter上）；
（1）初步猜想原因可能是因为AE中的网络层数中的维度设置过大的原因，因此打算对于gplus，一定要将维度设置小一点；

2022.09.28

1.DFCN在twitter上运行时，会出现维度不匹配的报错：
（1）原因是在训练前有一个主成分分析过程，但是twitter的子集中存在特征个数大于节点个数的情况，因此会导致主成分分析的维度设置存在问题；
（2）只有4个子集可以正常运行，因此在此处必须修改；
（3）修改方法：需要从pre_train一并修改，在pca分析时，设置维度为min(n_samples, n_dimension);
2.在使用进程池时，可以考虑不设置固定的进程数，直接按照默认处理，这样系统可以更加合理地分配；
3.DFCN在gplus上时，即便是pre_train, 运行效率也特别低；
4.DFCN在twitter上地结果特别好，高于我们模型许多；
（1）继续优化我们模型在twitter上的结果；
（2）详细演技一下DFCN模型，看看有没有什么可以值得借鉴的地方；
5.鉴于MAGCN非常耗时，因此决定将其每个view下的网络维度设置低一些；
6.MAGCN在各个数据集上的F1得分很高，后期需要对比一下F1的计算方式是否一致；

2022.09.29

1.DFCN模型在gplus数据集上跑了一晚上还没结束，耗时太长；
2.DFCN在已经跑出来的部分gplus子集上的结果非常好；
3.ARGAE和ARVGAE同样在gplus上非常耗时，因此只跑了其中86个数据子集；

2022.09.30

1.在facebook数据集上：
（1）当ACC和NMI同时大于上一次迭代时，我们更新当前最优值；
（2）F-score的计算采用f-micro的方式；
（3）通过采取（1）（2）两个trick，可以使得获得的结果在各个指标上都有较好的提升；
2.需要明确一点：
（1）虽然目前来看DFCN和MAGCN的在gplus上结果非常高，但是只是它们的部分子集的结果，实际上它们有很多子集的结果都没有跑出来；
（2）因此在这一点上，需要想办法将其所有子集结果都跑出来后再做对比才有意义；

2022.10.19

1.将tensorflow版本代码转为pytorch版本时，遇到的问题：
（1）tf.sparse_add(), 在pytorch中找不到对应的API；
（2）kmeans部分的代码应该如何写；
2.绘制facebook数据集的lambda参数分析的图时，图中柱子颜色区分不开：
（1）重新设置柱子的颜色区分方式；
	①通过将柱子颜色的区分方式改为[0,1]时，颜色看着好一点；
	②同时对cora和acm数据集也做了实验，效果也不错；
（2）说明我们的模型在social数据集上的结果是比较稳定的；
3.可以考虑是否将柱子的颜色和其他可视化分析的图的颜色调为一致？

2022.10.21

1.将loss的收敛曲线进行了绘制，包括total_loss, rec_loss, self_loss和fuzzy_loss，但是发现只有fuzzy_loss的值是减少的。

2022.10.28

1. the 的使用：on cora dataset 还是on the cora dataset？
2. our model 还是FGCNC?

2022.11.01

1.网络层维度有问题；
（1）在社交数据集中，当前子集完成后，flags.hid_dims会保持当前子集的维度，同时加上新子集的维度；
（2）所以这也是社交数据集耗时的原因，因为越到后面，相当于网络层数越多，因此更加耗时；
解决方案：
	每个子集训练完后，重新设置flags.hid_dims；

2022.11.14

1.在复现MAGC的实验时，发现几个问题：
（1）按照所给源码，跑出的ACM的结果比原论文中差很多；
（2）在跑cora等其他的我们的数据集时，结构无法multi-view；且属性设置multi-view时，程序报错；
（3）在运行social数据集时，评估指标出现负值的情况；