PhD story

这几天回想起来defense之后,advisor以及committee member说的congratuation之类的话,总觉得不够真实。心里有时会问问自己,这就结束了,真的结束了吗?

不太想写那种流水账一样的心路历程,大致记录一些当前的思考。整个phd学习的过程和大多数其他同学一样,算不上顺利,开始的两年找不到方向,和别人的合作也不算愉快。之后机缘巧合,遇到了能在具体方向给一些实际指导作用的collebarator,硬着头皮勉强发了几篇论文,凑够了毕业要求,没有很多的功劳和切切实实的contribution,但是总算是有一些苦劳吧,课程完成也算是兢兢业业,最后还要靠一些运气,比如老师催促着想让赶紧毕业,总算是按时完成了毕业要求。

想想看,这几年对于划水这个词似乎有了更深刻的了解,有的时候也不是说自己想划水,大概是客观情况下的一种折衷。看到很多人说自己之前的经历,phd阶段更多地是做一些solid但是不太novelty的工作,自己也有一点类似,有时候只能通过一些苦劳让reviewer觉得这个work还可以勉强接受。

就像面试的时候资历深的researcher所说的,从学生的角度讲,get some ideas and publish papers quickly 这样是好的,但是从researcher的角度上讲,你要关注right problem 而不是fake problem。其实越是资历深的research越是容易怀疑当前做的东西是不是一个fake problem。

答辩结束的几天,看见in-situ这个词就有点反胃,过几天才能安静下来整理一些思路。特别是弄完thesis,真的是不想再看一遍。这也从侧面说明了自己做的这些work整体的质量一般般。

但是安静下来,又想着还是要有点责任心,沉淀沉淀一些核心的想法和问题,看看以后做相关的事情怎么能更有意义一些。

Motivation of in situ processing

in situ的 main motivation 是 gap between computaion and IO 然后数据量很大,这时候disk IO就是瓶颈,然后很大量的data没法写到disk上来分析,或者IO的时间过长了,需要做analtyics before doing the file IO

但是事实上许多paper里面的用例和规模都没有达到这种IO是bottleneck的程度。不论是从scale上还是数据的量上。可以说大部分的时候in-situ是没有什么必要的,或者说作用不是很大。用一些快速的IO设备比如NVRAM等等,也是能提高速度的。这就是为什么ADIOS主要关注的是file based IO的格式,其他的就是也提供,但是并不是使用的那么广泛。好多时候论文里用到的例子甚至是workflow,实际的bottleneck并不在IO上面,还是computation和analytics,这样来看的话,整个worklfow在这种情况下的优化的重点还确实不是IO

最初说gap的时候是从整个系统的角度来说的,但是落实到具体的每个应用上,并不一定能把整个系统的computaion能力充分运用起来。比如一些toy problem,几十个节点的规模,其实用in-situ并不是很有必要,虽然确实比disk io快一些,但是并不是非要这样用不可,streaming的处理方式肯定是牺牲了一些数据的持久化和交互的便利性。

但事实上在research paper中,仿佛不提in-situ就不太行,缺少卖点,但是提了之后,又不是那么给力,比如有好多科学家并不认为in-situ能给他们提供多少实实在在的帮助,不仅技术实现上复杂又容易出错还不好debug。甚至包括一些资深的大佬也有这样的argument,确实这是事实情况,这就让新人有点左右为难的感觉。总体上所做的内容和motivation不怎么匹配,所以具体内容研究起来就很矛盾。

从I/O的角度上来讲,in-staging又不是特别有必要,甚至大佬之间对于这个staging based data transfer也是很有争议的一个事情,自己作为新人探索这几年,反而增加了更多的疑惑。甚至有的时候自己对于自己说的东西都有点牵强,也没有办法,但是这个就像是命题作文一样,需要在make sense的方向和导师的interests以及funding的来源上找到一个比较好的交集。

从staging本身最初的起源来看,还是作为那种coupled simulation之间互相share数据的场景比较稳妥,就是caching机制,然后有比较清晰的get和put的interface。

那最终的问题是,什么样的情况下in-situ是必要的呢?一些实际问题中的baseline是什么情况呢? 不涉及一些非技术因素的话,可以参考这个 数据量的话大概是每秒大概要几十GB的规模吧,总之就是满足,如果不用in-situ,就确确实实写不下数据,这么一个情况。这个也是几年前的数据,in general,从workflow的角度来看,要看IO是否是一个比较明显的bottleneck。如果这个overhead相比较sim和ana的区别并不是很显著,那使用in-situ的意义也不是很大,因为引入了很多额外的overhead.

用high performance visulization的书中的话(15.4.1.1),Indeed, because data reduction must occure in the scientific analytisi pipeline in extreme-scale computing(because of the IO gap issue mentioned above), only during the simulation will all relevant data bout the simulated field, computational domain, and related fields be avalibale at the highest fidelity. This scenario is key to in situ processing – that data must be intelligently reduced, analyzed, transformed and indexed while still resident in memory before leaving the machine (or the same system).

当然从research的角度上讲,单纯从方法本身来看,tightly coupled in-situ用来做reduction还是比较好的场景,能确实减少一些IO的overhead. 使用loosely coupled in-situ的意义似乎不是太大,这里的data consumer直接是visulization code比较合适。就像是colza里使用的那种场景。相当于是sim作为source,vis直接作为consumer这样使用。

这个图是参考的这本书 (这本书还是比较推荐的):

High performance visualization: Enabling extreme-scale scientific insight[M]. CRC Press, 2012.

里面的Figure 9.6更新了一些相关的term,怪不得大佬说这10多年这个research area都没有多大的进展,其实确实如此,拿出来这个图来看,确实发现和现在相比是没有很多的变化,这个图可以作为以后给别人讲相关work时候的一个background部分,感觉这个表达方式相比于纯粹的文字要清晰很多 (特别是介绍两种具体的loosely-coupled的实现方式的时候,一种on-node一种off-node)。有了这个图作为铺垫,再讲一些后续的工作就比较自然,比如这么多的地方可以执行analytics,放在哪里执行比较有合适,然后dedicated computing machines的elasticity的问题,以及合适传输数据处理数据,trigger analtyics的问题等等。

除了之前说的data amount大到一定程度,不得已要使用in-situ之外,书上还介绍了一些其他的in situ的适应场合。”In situ vis is most approporiate when end users know what they want to look in priori” 这个和实践的结果类似,根据自己最近的一些经验,通常是使用post processing把需要弄的内容处理好,比如使用paraview catalyst调整好一些合适的参数和view,之后把这个操作固定下来,按照一个template的方式integrate到in-situ的pipeline中。或者是in-situ的方式进行一些数据的preprocessing,仅仅保留一些对于post-processing有用的数据。

因为data exploration的过程通常是很久的并且这些时间难以预料,domain scientists需要很多时间来分析,所以data exploration本身不太适合使用in-situ的方式来进行,这也就是post-processing必不可少的地方。所以大致流程是 post processing 和 in-situ processing 交替进行的过程,post-procesisng 得到一些knowlege,然后in-situ processing 筛选出新的数据,然后再 post-processing 这样反复进行。从这个角度来看,in situ 和 post processing 似乎是在一个轴的两端,一个是有很好的speed improvement但是不够flexibility另外一个是很好的interaction但是speed不太行。

Tightly coupled vs Loosely coupled, which is better

对于这个问题从技术的角度上看,整理的比较好的就是这一篇

Kress, James, et al. “Loosely coupled in situ visualization: A perspective on why it’s here to stay.” Proceedings of the First Workshop on In Situ Infrastructures for Enabling Extreme-Scale Analysis and Visualization. 2015.

loosely 和 tightly 是两种方式 (or inline insitu and in-transit),具体什么样的方式比较好肯定是根据具体的使用场景而言的,在一些视频中也有提到 (比如这个 https://www.youtube.com/watch?v=uKaDNW-2m40 19:55的地方)

关键在实施或者做事的过程上,大家并不全是按照技术的角度来处理问题,比如老师的funding如果有的时候来自于某一个具体的项目,这个时候就binding在这个项目相关的技术方向上了,就比如我自己的经历,基本上是我们这个组的所有的research都是在做in-transit相关的,这就导致了论文里好像有时候并不足够客观,reviewer可能有时候就会问,为什么用这个方式不用那个方式?用这个方式的好处在哪里?这种问题有时候很难回答,因为可能两种方式差不多,或者使用某种方式其实不是特别有必要的,但是由于一些非技术的因素,让你使用了某个特定的方式。

从赶快出成果的角度讲,这种时候自己就选择了一个范围更广的课题,能把这两种方式都包含进来,这样从技术的角度和非技术的角度都是一个交代。

但确确实实还是应该更加实事求是一些,看看自己的应用场景是否和使用的相关技术比较匹配,这样更convincing一些。

The lack of application scenario and actual data

开始的时候无从下手,直到有了gray scott的sim的code,说起来都是一些简单的sim,但是作为一些proof of concept的项目也足够了。

这一块儿归根结底还是要figure out workflow到底是什么。就算thesis的writting,前几章的motivation也还是关于workflow以及相关的requriements的描述。

More concrete research domains

之前的选择的topic其实是属于相对简单一些的,比如in situ的那些topic,基本上稍微看一下都知道怎么回事,但是想继续在相关的领域有所发展的话,还是需要做一些更细致的内容。比如IO,compression,reduction或者是vis的pipeline。从vis的角度来看的话需要更关注的就是vis本身的pipeline,然后这个pipeline是怎么和insitu的pipeline结合起来的。

比如这个文章里面的图强调的几个stage,importing,filtering and enriching,mapping以及最后的rending。

从vis的pipeline的角度来看,它就是另外的一个research domain了,这个research domain的重要应用是和in situ processing 结合起来。因为in situ processing 本来只是一种architecture,并不是说非得按照这个方式来进行,相当于是一种形而上的方式,如果说research domain是in situ processing 就不太能走长远,再泛一点大致算到是workflow的研究领域。总之要有一个相对更solid的领域,更通俗一点说,就是关注方法上的一些改进,比如做这个事情,可以按照insitu的方式,也可以不按照insitu的方式,具体做的内容也不会受限于当前的技术,反而是根据技术的发展不断改进和提升。

Scratch

从理解的角度上讲,和别人在专业的问题上进行交流的时候,对于语言和思维的把控上还是不行,如果别人一下子说一大段话,就有点脑子发懵,或者问相关的问题,有点跟不上节奏,可能是对于英语的解析能力还是有限。

付出了一些时间,甚至牺牲了一些健康,还是挺想做正确的事情的,到最后发现只是make a living。

或者就是从vis的角度出发,采用都不得罪的办法,比如一个新的点,然后用tighly-coupled实现一下,用loosely coupled 实现一下,这个样子。

今天参加了学校举行的hooding process,和别人说起来也算是知道这个hooding ceremony是怎么回事儿了,中文翻译成为博士披肩似乎是比较make sense的表述,本科时候的毕业的仪式是拨穗。感觉还是挺有仪式感的,亲戚朋友过来一起庆祝毕业还是一个挺有意思的时候。如果老师能过来hooding process就真的是很nice了,整个上午的时间每个人hooding的时间只有那么几分钟,老师要是能抽空过来那真的是对于学生来讲有很大的纪念意义了。不过听台上讲话的人讲东西的时候有些心不在焉,只顾着在纪念册上找自己的名字,似乎没有留下很多能和别人分享的记忆点。

推荐文章