一、pyscenic的结果不可重复

最近在运行pyscenic的结果的时候发现了两次相同参数相同数据的结果存在不一致，回溯发现scenic的第一步GRN的结果已经出现了差异，转录因子和目标基因之间的importance发生了变化，同时整体的importance排序也已经不一样了，如下：

GRN结果实例

同样的环境、数据和脚本，结果不一样，就会怀疑是随机因素导致的，虽然中文检索没有人解答，但是在github，pyscenic的团队还是给出了解释：

不可重复性的解释

大概意思是运行scenic第一个部分的GENIE3/GRNBoost本身就会存在随机性，作者也是推荐大家为了保证的可靠性，可以通过多次运行取均值的方法来解决。

好，既然不是自己的问题，那就相当于问题解决。不过，其实仔细发现，每一次运行GRN结果虽然不一样，但是差别不会说特别巨大，基本上显著相关的基因都还是在的，只是具体的importance存在一些差异，但其实后面通过过滤，许多低质量的GRN关系都会被过滤掉的，这也就是说为何许多高质量文章的结果都能大概的复现出来，尤其是核心的结果还是比较靠谱的。

二、关于运行矩阵的要求

其实另一个比较困惑的问题就是，在运行pyscenic或者scenic的时候，到底用counts矩阵还是标准化处理之后的矩阵呢？这个帖子刚好提及到了，我也就顺便总结一下。

如果是单个数据，答案肯定是最好用counts矩阵，这也是官方建议的，因为scenic内部也会进行相似的数据预处理，所以最好用最原始的counts矩阵，保留的生物学信息也最原始。
那么就会涉及到一个问题，如果我有多个样本的数据呢？counts矩阵之间必然会存在批次效应，而这种样本间的批次其实对相关性的判断影响还蛮大的（当然GRNBoost存在一定的鲁棒性），这个时候我是应该继续用counts还是用整合之后去除了批次效应的表达矩阵呢？
hh官方的建议还是蛮中肯的 yes or no，他回答or。建议大家不要用整合的数据（存在大批次效应的数据）一次性地去做scenic，最好是一个个样本跑，最后取交集/均值，从源头解决问题。当然，他也承认，如果非要用整合的样本，适当的校准批次效应也是可以的（例如Seurat的SCTranform），但对结果肯定会有一定的影响。同时，其实我们其实可以自己尝试一下，整合样本的counts/处理后的矩阵/各个样本单独运行的结果，三种情况做一个综合考虑，才最合理。（其实基本上，按我个人的经验来说，如果只选top的话，应该都大差不差，因为显著的永远是最突出的，但如果要focus细微差异的基因的话，大家就需要严谨且谨慎对待自己的分析结论了。）

总而言之，本身基因网络分析GRN的结果就是挺玄学的，受到诸多因素的影响，所以大家可以结合其他结论，例如文献和实验来确保最终结果是可靠的，大胆分析小心验证即可。