tyn1998 / master-project-2024

2024年硕士毕业设计. Master's project in 2024.
The Unlicense
2 stars 1 forks source link

[Discussion] 如何结合现有成果确定毕设的主要工作点,如何串联起一个故事 #2

Closed tyn1998 closed 8 months ago

tyn1998 commented 9 months ago

开题时的 Issue 在这儿:https://github.com/X-lab2017/open-research/issues/175

此 Issue 的 Description 会持续更新,欢迎大家在评论区讨论~


tyn1998 commented 9 months ago

https://github.com/X-lab2017/open-research/issues/175 中,我提到的网络是包含仓库、开发者、issue、PR的异质网络。现在,有了atom-galaxy的研发成果 & 出于可行性的考虑,我觉得网络和 OpenGalaxy 2D保持一致,即一个只包含仓库结点的同质网络。对于这个网络,我的主要重心应该放在结点的聚类、可视化性能和效果上,让这个网络真正具有实用性,而不仅仅看着炫酷而已。

上面是宏观层面的目标,到了微观层面,其实就是点击某个仓库节点后,atom-galaxy的用武之地就来了。每个仓库视图中,是一个”仓库-开发者-issue&PR“三层星系:

image

目前是有这么一个宏观+微观的大概想法。毕设结束后,OpenGalaxy更新到3.0版本 :)

frank-zsy commented 9 months ago

挺好的,这样在不需要修改 OpenGalaxy 大框架的同时又可以快速合入一个细节,但交互上是否可以做到顺滑切换是一个问题。

tyn1998 commented 9 months ago

重新评估了一下开题时的几个工作点,有一些思考:

1、保持开题时定义的”协作网络“ 2、一个”全域“→多个”局部“

https://github.com/tyn1998/master-project-2024/issues/2#issuecomment-1901711032 中,我放弃了异质网络,现在觉得这样不大合适。由于论文标题有“协作网络”,且开题内容里也确定了协作网络是(两类节点+三类有向边),我觉得一个“协作网络”没有开发者是不大对头的。所以还是要构建这么一个协作网络,但是范围不要全域了,而是限定范围。

什么是“范围”?初步设想是利用OpenDigger的Project标签数据,例如:https://github.com/X-lab2017/open-digger/blob/master/labeled_data/projects/skywalking.yml 。把属于一个Project的所有repos中的事件拉出来,然后构造我在开题中提及的“协作网络”。以后可以推广到Community、Company、Foundation等。于是,一个全域变成了多个局部,优点有:

  1. 减少处理数据量,无论是数据库的导出,还是网络布局的计算时间
  2. 更聚焦更有意义,就像开源年报分类的OpenRank排行榜一样

3、保持3D形态 4、OpenGalaxy新增Atom Galaxy,原有的形态就叫做Graph Galaxy

我现在脑中的应用形态是这样子:

image

  1. 进入OpenGalaxy应用,现在有两种galaxy:Graph Galaxy 和 Atom Galaxy。前者是协作网络的可视化,后者是OpenRank构成和排名的可视化。例如设计图中,Graph Galaxy列表中有 Skywalking 项目,说明用户可以查看这个项目的graph galaxy(graph galaxy即毕设中的开源协作网络)。
  2. 选择某个 graph galaxy 后,就进入了可交互的3D网络,这个形态和目前的OpenGalaxy 3D差不多,但是网络布局会显著提升(hopefully) 。选择某个 atom galaxy 后,就进入了形同开放原子大屏那样的应用。
  3. 继续以 Skywalking 为例,如果还支持该项目的 Atom Glaxy 数据,那么在进入 graph galaxy 后,还支持切换到相应的 Atom Galaxy。反之亦然。

5、砍掉演化过程的可视化 6、WebGPU降级为WebGL

由于时间关系和难度关系,动态网络演化和WebGPU需要战略性放弃。动态演化过程指两个月份之间过渡的时候会有动画,在有限的时间里应该做不到了。本来想用WebGPU做应用,但是由于网络规模变小了,演化过程被砍掉,那渲染压力几乎没有,不需要WebGPU;另外做3D应用,目前我只能使用Three.js框架来做(此框架还未完全支持WebGPU),基于WebGPU的生态还很不繁荣,裸写也不现实。

7、修改论文标题

综上,请 @will-ww 王老师帮忙判断一下是否可以这么改,如果可以的话,我还希望把论文标题从”基于 WebGPU 和力导向布局的开源协作网络可视化研究“改成”基于 WebGL 和力导向布局的开源协作网络可视化研究“,是否可行?(WebGPU改成WebGL)

tyn1998 commented 9 months ago

上述 Graph Galaxy 的网络布局算法应该作为该毕设的核心创新点。但这个创新(改进)之处不是体现在布局算法的性能速度上,而是美学指标的提升上。看过几篇论文,发现作者会自定义一些美学指标(自己制定评判规则),然后将同一个图在自己的布局算法和别的布局算法上跑,从而得出不同的布局算法在作者自定义的美学指标下的评分。

这给我启发,我是不是也可以定义一套美学指标,这套美学指标评价什么样的布局才是好的开源协作网络布局。然后拿我届时提出的布局算法和其他若干个经典算法跑出来的布局在这套美学指标下做个比较,只要我的算法能够胜出就行。

于是先要解决的问题是:什么样的布局才是好的开源协作网络布局?

will-ww commented 9 months ago

上述 Graph Galaxy 的网络布局算法应该作为该毕设的核心创新点。但这个创新(改进)之处不是体现在布局算法的性能速度上,而是美学指标的提升上。看过几篇论文,发现作者会自定义一些美学指标(自己制定评判规则),然后将同一个图在自己的布局算法和别的布局算法上跑,从而得出不同的布局算法在作者自定义的美学指标下的评分。

这给我启发,我是不是也可以定义一套美学指标,这套美学指标评价什么样的布局才是好的开源协作网络布局。然后拿我届时提出的布局算法和其他若干个经典算法跑出来的布局在这套美学指标下做个比较,只要我的算法能够胜出就行。

于是先要解决的问题是:什么样的布局才是好的开源协作网络布局?

你前面说的,我觉得都没问题(特别是WebGPU改成WebGL),关键是能够顺利先把论文完成。目前主要还是考虑第二个工作点究竟是什么,实验如何做,和什么比较,第一个(建图)和第三个(应用)肯定没问题,都是我们的强项,而且很有基础。

如果能够快速将“什么样的布局才是好的开源协作网络布局”,这个问题定义清楚,当然是比较理想的,但感觉不是我们熟悉的领域,不知道从参考文献中是否能够快速找到合适的参考。

退而求其次的做法包括:

tyn1998 commented 9 months ago

首先感谢王老师的回复!这几天读了些文献,又改变了思路 😆 还没有彻底厘清,但是今天打算开始先动手了,把网络构建的工作先跑起来。想清楚了后会画一个精致的图放到这里。

注意:下面的内容都是 WIP,仅供参考

抽取引用关系 -> 确定有向边权重并构建网络 -> Infomap聚类 多层级、with metadata -> Multi-level Graph Drawing 三步法(QM对比实验放在这里) 、边捆绑(这里可以有视觉效果对比,非定量对比) -> 2.5D应用(层内2D、层间3D)

融合引用与提及的开源协作网络;

对比:数据集用论文提出的开源协作网络的一个例子,然后拿三步走后的布局在经典美学指标(Quality Metrics)上的表现和没有聚类过直接力导向出来的布局比。

这个标题“基于聚类的开源协作网络可视化研究”怎么样?

毕设工作点

tyn1998 commented 8 months ago

论文预审版本已完成,绪论在这里:

image

非常感谢大家的建议!