如何从最终的vcf文件识别SV类型

[Min84-dl]

你好，郑博士！

请问使用panpop从TGS数据检测到SV获得最终vcf（15.thin3.sv.vcf.gz）后，如何从中识别SV的类型（插入、缺失、重复...）呢？

感谢！

[starskyzheng]

您可以根据第3,4列（ref/alt）判断。 比如第三列只有1个碱基，第4列很多碱基，就是插入。反之就是缺失。 重复类型没法判断的，只能算是一种特殊的插入。

[Summer0lhl]

郑博士，你好！请问，最终的 vcf 文件里面没有倒位和易位吗？

[starskyzheng]

有，但是不会标记出来。 易位相当于一个缺失和一个插入

[Summer0lhl]

郑博士，感谢您的及时回复！

易位的标志就是 ref 或 alt 列有出现*出现。 倒位的标志 ref 和 alt 碱基数目相同。

不知这样理解是否正确，不过，从我的结果里面去筛选碱基数目相同的条目，搜索出来的结果但是看着不像是倒位呢，这样的是什么情况呢。

[Summer0lhl]

郑博士，你好！今天查阅了软件的代码，如果就按照github 上面提供的示例运行，最终的15.thin3.sv.vcf.gz文件，里面没有易位，也没有倒位，结果里面只有INV，DEL，和 DUP； （1）在每个软件call sv 后，都有经过有long_caller_parser.pl来处理，在脚本内部，只保留了INS,DEL和DUP，TRANSLOCATION都没 next 没了;所有最终结果里面没有TRANSLOCATION; （2）最终文件里面也没有INV，按照示例文件跑，到 long_caller_parser.pl 的时候，我发现这个脚本有个参数-out_inv，默认就把INV 给独立出去了。到运行mergeSV3.py的最后一步，又运行 bcftools concat 把它合进去了。不过运行mergeSV3_pop.py时，压根没有用到INV，而是用bcftools merge命令对不同样本的04_consensus_vcf//09.thin2.sorted.vcf.gz进行的合并，接下来的一番操作里面再也没有出现INV了，所以如果按照示例默认模式下跑，最终结果文件里面也不会有INV。 （3）我的结果 vcf 文件里面有大量的 ref/alt列是，追踪了来源，这些 其实在各个软件call sv 出来的vcf文件里面都是正常的，就是在realign后，有某个碱基在ref和alt是相同的，给替换了，就出现了 ，本来是标准的INS 和 DEL模式的。这种处理是否合理呢。

盼回复！

[starskyzheng]

*不是易位的标志，只是说明这个allele是个缺失。ref和alt一样长，也说明不了突变类型的。

关于倒位，抱歉我第一次说错了，目前确实倒位我没有在群体合并中使用。本来计划是像单个体一样的单独合并倒位突变，但是后来没来得及。倒位最好不要和插入缺失一起分析，会在align时引入较大误差。

关于TRANSLOCATION，比如Sniffles2的结果，就只有很模糊的信息，比如原始位置和新位置，没有长度、序列等信息，很难整合到一起，就跳过这些了。

第三条我没看懂，您能说细点么。

[Summer0lhl]

郑博士，不好意思，第三条当时看错了。

最终结果文件里面如果第三列能保留变异的类型就好了，要不然大家都重复造轮子，各自去对最终文件的变异类型进行分类。而且大家在分类的时候，仅仅按照ref列和alt列的碱基数目来比较，就很容易把DUP归为INS 或者DEL，最终就没有DUP类型了。那些变异类型，在 merge_vcf_same_pos.pl 那一步就没保留下来第三列的变异来源，在这儿之前其实可以根据第三列来判断变异类型的。

如果后面对软件进行更新维护的话，建议能保留变异类型。

[starskyzheng]

这个在panpop的框架下很难，因为panpop的核心是realign，会重构所有的SV，势必会丢失掉SV原有的类型等信息。

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.