Some ideas regarding the workflow management.
It seems like the research direaction such as workflow is like a two edged sword, the easy things is that it is general, when you discuss the workflow, basically you can discuss all things. The bad thing is that, it is too general.
当做了一点东西但是又不是很具体的时候就可以往workflow的方向上靠，从workflow的视角上来看，总能把你做的内容包含进去。
但是从另一个角度来看，这样的工作内容似乎是很不具体，有那种划水的嫌疑，所以我自己总是自嘲，做workflow相关的research是处于research鄙视链的最低端。
但是不得不说，再没有什么能做的时候，或者所在的领域上手比较难的时候，做workflow至少是一个容易上手的option，最起码能让你先做出一点东西。 仿佛是越不想做什么就越容易做什么，master的时候有一段时间就天天弄paas平台的安装脚本，老师看了之后说要不master的论文就弄workflow得了。后来有一段时间工作经历，所在的项目组又是弄worklfow的，就是管理各种资源如何创建，如何给user提供一个完整的表达然后把每个小的步骤拼接在一起。
在phd阶段，也还是绕不开workflow的话题，知道的几个phd的thesis也都是在弄这个workflow相关topic，不管怎样反正能找到research的点还能毕业。有时候也常常会感觉能看的都被看过了，想到一个点仔细一找，总能发现类似的点，于是又要花一些心思再继续想想，看是否能再refine一下这个点，然后有所提升。比如最近想到的一个点觉得挺好，colleagues之间一聊，发现别人已经弄了一些基本的工作。看完别人做的内容，就是感觉自己想到的idea有一种呼之欲出的感觉，要是自己不弄，别人可能就马上发表相关的内容了，所以要赶紧弄，先抢占一个位置再说。
从research的角度讲，你所关注的workflow是什么是一个要花大力气解释清楚的问题，比如在thesis可能需要要拿出一个chapter来着重讲关注的workflow是什么样子的。但是好的research肯定是要关注workflow的背景，但是又不能仅仅是关注workflow层面的contribution，还要透过workflow再找到一些更具体的点(深入到workflow中的某个application的层次上)，这样才能有比较足够的depth。
最近和colleages的一些讨论常常能带来新的insights。其实就是分类的问题，大的domain是scientific workflow，之后具体细分的时候一定要首先问问看是关注哪种workflow，这样才好一起聊，粗略的一些包括：
coupled workflow (multi-physics coupling)
post processing workflow
Sensor output processing
Instrument output processing
in situ workflow
ensemble workflow
Al/ML trining workflow (AI surrogate)
慢慢的会出现一些新的类型的workflow，比如simulation和AI结合起来的workflow。自己的一个新的research问题，首先要看看是放在哪个workflow场景下，对这个类型的workflow有一个很宏观的了解，弄清数据在不同组件之间是怎么互相传输的，不同组件的依赖关系是什么，然后再深入挖掘下去，看看具体的research 的contribution是什么。
