TAPIS使用笔记

作者：Hector Zou

TAPIS(Transriptome AnalysisPipeline from Isoform Sequencing)是一款依赖Python2.7的，用于分析校正和比对长读段、转录本聚类、新转录本和全长转录本可变剪切检测以及鉴定分析poly（A）和可变poly(A)（APA）的一款软件；发表于Nature Comunication 2016年6月的一篇关于高粱转录本可变剪切和可变Poly(A)的研究的文章[1]。目前，一些测序分析公司的全长转录组分析流程经常用到它。当前最新版本为2016年3月发布的1.2.1[2]。以下几个是TAPIS的主要功能脚本：

alignPacBio.py用于将全长转录本回帖到基因组，依赖于软件GMAP[3,4];

cleanAlignments.py清理bam中未回帖的长读段；被alignPacBio.py调用;

convertSam.py调用samtools进行格式转换、sort和index；被alignPacBio.py调用；

run_tapis.py分析可变剪切和APA。

笔者在使用的过程中发现一些问题，主要是alignPacBio.py的使用错误和run_tapis.py输出结果要注意的问题。

（1）运行出现catDen_catenatum_v0814.fasta无法找到该命令，应该是alignPacBio.py的脚本出错了。脚本中的cat后应该加上空格，即79行的prefix = ’cat’改成prefix = ’cat ’，如下图所示。网上的脚本已经改正的了，但是不懂为什么下载安装后的是没有改正的。

（2）运行alignPacBio.py出现以下图中错误。cat: write error: Broken pipe …… (core dumped) gmap ……。

尽管错误中提及cat,这可能是由于下面的程序调用奔溃，使得cat的管道传输数据无处可传而报错。笔者为了找解决办法，上Google和Bing苦找了很久，也没找到答案。其实在TAPIS的issue页中就有人曾提出过这个问题（https://bitbucket.org/comp_bio/tapis/issues/6/alignpacbiopy-error#comment-41299994），只不过其解决办法却是针对上面的一个问题。历经四个多小时的查找，本来要放弃的。突然女神来临，不能随便放弃。尝试去看看一个输出日志（下图），发现错误的问题可能出现在内存分配上。我去（请看下图红框处），要分配“辣”么多内存，把笔者卖了也凑不到这么大的内存空间。笔者的机器128G，PC中已经算“碉堡”的了，却是“滴水”车薪。

alignPacBio.py的参数是无法限制或者分配内存的；那就去脚本里面刮一下。发现其调用的gmap的参数中有一项是与内存分配相关的，即--expand-offsets，如图。

当--expand-offsets设置为的时候，gmap运行慢，节省内存。

当--expand-offsets设置为1的时候，gmap运行加快，需要大量的内存，也就是用空间换时间的“把戏”；这是alignPacBio.py调用gmap所采用的默认参数。

尝试把alignPacBio.py中的--expand-offsets设置为后，该脚本正常运行。

（3）run_tapis.py输出的assembly.gtf中的CDS是错误的，应该丢弃，不要迷信软件的输出结果。生成CDS的话，可以用Transdecoder [5]。

Reference

[1] Abdel-Ghany,S. E., Hamilton, M., Jacobi, J. L., Ngam, P., Devitt, N., Schilkey, F.,Ben-Hur, A., and Reddy, A. S. N. A survey of the sorghum transcriptome usingsingle-molecule long reads. Nature Communications, 2016 7:11706.

[2]https://bitbucket.org/comp_bio/tapis

[3]Thomas D. Wu and Colin K. Watanabe GMAP:a genomic mapping and alignment program for mRNA and EST sequences. Bioinformatics,2005 21:1859-1875.

[4]Thomas D. Wu andSerban Nacu. Fast and SNP-tolerant detection of complex variants and splicingin short reads. Bioinformatics, 2010 26:873-881.