2016년 9월 2일 금요일

MetAMOS under Linuxbrew (CentOS 6.7)

MetAMOS란?

NGS 기술을 이용한 (meta)genome의 분석을 용이하게 해 주는 통합 도구이다. 설치 과정을 통해 매우 많은 공부를 하게 해 줄뿐만 하니라 수십 가지의 third party program들을 한번에 체험하게 해 준다. 내가 파이썬을 제대로 익혀야 되겠다는 생각이 들게 된 것도 바로 MetAMOS의 설치 스크립트를 현재 실정에 맞게 고칠 필요성이 대두되면서 부터이다.

설치를 위한 주의 사항

파이썬 2.7.3+과 gcc 4.7+이 필요하므로 CentOS 6.x에 설치하려면 보통 어려운 것이 아니다. KOBIC 전산팀의 도움을 받아 어느 정도 돌아가는 수준으로 만들기는 했지만, 최근 Linuxbrew를 체험하게 되면서 수퍼유저 권한 없이 아주 용이하게 재설치를 마쳤다. Linuxbrew에서 필요한 것은 python과 expat 정도이다. $ brew install python이라고만 하면 gcc 등 다른 필요한 것들도 알아서 전부 깔린다.

metAMOS 빌드를 위한 개발 환경이 완벽히 갖추어졌다 해도 몇 가지의 문제가 남는다. 2014년에 배포된 최종 버전의 설치 파이썬 스크립트(INSTALL.py)에 설정된 third party program들의 download URL(CBCB 외부에 위치)이 이제는 유효하지 않은 것이 점점 많아지고 있기 때문이다. 이런 것은 웹 상의 다른 곳을 뒤져서 파일을 구한 다음, local web server에 올린 뒤 INSTALL.py에 해당 주소를 바꾸는 식으로 수정을 해 나갔다. 실제로는 너무나 설치 연습을 많이 하게 되어서 미안한 마음(?)에 MetAMOS 주요 프로그램(ftp://cbcb.umd.edu/pub/data/metamos에 위치)도 전부 로컬 서버로 옮겨서 이를 다운로드하도록 설치 스크립트를 대폭 수정하였다. 단, http://www.cbcb.umd.edu/software에 보관된 프로그램은 원본 위치를 그대로 사용하고 있다.

다운로드 URL이 바뀐 third party program 중 가장 고약한 것은 prokka가 필요로 하는 internal-1.1rc4와 hmmer-3.1b1이다. 원본 설치 스크립트에서는 바이너리 패키지가 http://selab.janelia.org/software/infernal/ 아래에 각각 존재하는 것으로 되어있지만, 현재는 컴파일된 바이너리가 아니라 소스 패키지가 다른 장소에 존재한다. 따라서 소스를 따로 받아서 빌드한 뒤 $PATH에 올린 다음, MetAMOS 설치 스크립트를 돌려야 한다. 즉 Utilities/cpp/Linux-x86_64/prokka/binaries/linux에 있는 바이너리(aragon, blastp, cmscan, hmmscan, makeblastdb, nhmmer, parallel, phmmer 및 prodigal)이 제대로 실행 가능한 바이너리 형태를 하고 있는지를 확인해 보라. 그래야 prokka를 돌릴 수 있고, 이는 iMetAMOS 워크플로우를 돌리기 위한 기본이 된다.

소스에 포함되지 않은 대용량의 데이터베이스는 프로그램 설치 중에 직접 다운로드하게 된다. 그런데 가장 골치아픈 것은 박테리아의 유전체 서열 파일을 전부 하나로 묶은 다음의 파일이 이제는 존재하지 않는다. 좀 더 정확히 말하자면 수년 전의 파일이 더 이상 업데이트되지 않은 상태로 다른 위치로 이동했다는 것이다. 따라서 INSTALL.py를 적절히 수정해야 한다. 

ftp://ftp.ncbi.nih.gov/genomes/Bacteria/all.fna.tar.gz (이제 존재하지 않음)
ftp://ftp.ncbi.nih.gov/genomes/archive/old_refseq/all.fna.tar.gz (새로운 위치)
ftp://ftp.ncbi.nih.gov/genomes/Viruses/all.fna.tar.gz (이것은 아직 존재)

소스로부터 설치하기

Linuxbrew를 설치하고 파이썬과 gcc를 최신 버전으로 만들어 놓았다면 큰 문제 없이 MetAMOS를 설치할 수 있다. 유저 가이드에는 몇 가지의 Perl 모듈과 파이썬 패키지, 그리고 기타(boost, cmake, jellyfish & sparsehash)를 prerequiste로 제시하였는데, Perl 모듈을 제외하면 INSTALL.py 설치 과정에서 자동으로 설치되는 것으로 여겨진다. 내가 설치한 방식은 다음과 같다. DB를 깔지 않으려면 nodbs라는 옵션을 뒤에 붙이면 된다.
$ python INSTALL.py core
$ python INSTALL.py iMetAMOS
$ python INSTALL.py optional <= 26개 볼륨으로 구성된 RefSeq protein DB를 다운로드하고 처리하는데 무척 많은 시간을 보낸다.
python INSTALL.py core phylosift와 같이 설치하고 싶은 워크플로우와 프로그램을 인수로 나열해도 된다. nodbs 옵션을 주면 다음의 DB들이 설치되지 않는다. 콜론 뒤에 표시한 것은 DB 파일들의 위치이다. 기본적으로 $METAMOS_ROOT/Utilities/DB 하에 대부분 설치된다.


  • Kraken database: $METAMOS_ROOT/Utilities/DB/kraken/taxonomy
  • KronaTools taxonomy data: $METAMOS_ROOT/KronaTools/taxonomy
  • Uniprot/Swissprot DB for functional annotation: $METAMOS_ROOT/Utilities/DB
  • Genome model for FCP/NB (classifier): $METAMOS_ROOT/Utilities/DB/blast_data
  • refseq_protein blast DB for phmmer classification?: $METAMOS_ROOT/Utilities/DB
  • RefSeq genomes (bacteria and viruses .fna files) for recruitment of references (validation step): $METAMOS_ROOT/Utilities/DB/refseq
  • glimmer-mg models: (deprecated, not use) <= 나중에 좀 더 언급하겠다.

설치가 끝났으면 Utilities/DB/kraken에 Kraken DB가 제대로 설치되어있는지를 확인해 보라. 디렉토리 내용물이 최소한 다음과 같아야 한다. 


명시적으로 nodbs를 선언하지 않았지만 메모리가 100 GB 미만이라면 miniKraken DB를, 그 이상이라면  standard Kraken DB를 만든다. Standard Kraken DB는 NCBI에서 taxonomic information과 RefSeq complete genome(bacterial, archaeal, viral)을 전부 받아서 만드는 매우 방대한 작업이다. 만드는 방법은 여기에 있다. Kraken DB를 직접 만들때 jellyfish를 사용하게 되므로(version 1만 가능), 더불어서 jellyfish의 설치도 진행된다. 설치 스크립트를 열어보면 miniKraken은 Utilities/DB/kraken/minikraken_20141208에 깔리게 되었다. 만일 miniKraken DB를 사용하려면 디렉토리 내용물을 Utilities/DB/kraken으로 한 단계 올려야 하는 것은 아닌지 모르겠다.

가장 마지막에 설치 테스트를 하고 나서 확인해 보니 이 디렉토리는 library와 taxonomy의 두 개 디렉토리만 덜렁 있는 상태였다. 아마도 RefSeq에서 방대한 데이터를 다운로드하는 것이 어려워서 제대로 완료되지 않은 상태로 다음 스텝으로 진행한 것이라 생각된다.

Linuxbrew가 만능은 아니다!

현 버전의 Linuxbrew가 제공하는 파이썬 2.7.12는 아주 마음에 들지만 gcc 5.3.0은 MetAMOS가 요구하는 것(gcc 4.7+)에 비해 지나치게 높은 버전일 수도 있다. 특히 FRCbam과 boost library의 컴파일이 잘 되지 않는 것을 발견하였다. 이 문제를 극복하고자 다음의 과정을 거쳐서 gcc 4.9.2를 설치하면 최소한 FRCbam(+boost)까지는 에러 없이 컴파일이 된다. 그런 뒤에 MetAMOS를 설치하면 무난하다. 처음부터 이것을 쓰면 잘 되지 않았다.
# yum install centos-release-scl
# yum install devtoolset-3-toolchain
$ scl enable devtoolset-3 bash
Linuxbrew에서 설치가 잘 되지 않는 third-party program의 해결 방법에 대해서는 최근의 포스팅을 참조하라.

순탄치 않은 첫 테스트 실행

설치를 마쳤으니 기대를 안고서 다음의 첫 테스트 실행을 해 보라.
$ cd ./Test
$ ./run_pipeline_test.sh
run_pipeline_test.sh 스크립트는 이렇게 생겼다.

#/bin/sh
../initPipeline -f -m carsonella_pe_filt.fna -d test1  -i 500:3500
../runPipeline -a soap -c kraken -g fraggenescan -p 15 -d test1 -k 55 -f Assemble,MapReads,FindORFS,Annotate,FunctionalAnnotation,Propagate,Classify,Abundance,FindScaffoldORFS -n FunctionalAnnotation

메시지가 화면으로 잔뜩 지나가면서 뭔가 실행이 되는 것 같다가 빨간색 에러 메시지가 나오면서 멈춘다. FindScaffoldORFS 과정에서 에러가 발생한 것이다. 


이것은 기본적으로 설치된 FragGeneScan 바이너리의 호환성에 문제가 있어서 그런 것이다(issue #179). 이에 대한 해결책으로 GitHub의 MetAMOS 페이지에서는 MetaGeneMark를 각자 받아서 사용하라고 조언하였다(issue #94). 라이센스 문제로 인하여 성능이 더욱 좋음에도 불구하고 MetaGeneMark를 MetAMOS 패키지에 포함하여 배포하지 못하는 것이다. MetaGeneMark의 실행파일(gmhmmp)을 $PATH에 추가하고 라이센스 키 파일(.gm_key)를 홈 디렉토리에 복사한 다음, 실행 스크립트에서 -g fraggenscan을 -f metagenemark라고 고치면 된다.

FindORFS를 MetaGeneMark로 고쳐놓은 뒤 run_pipeline_test.sh를 실행하였다. 파이어폭스가 뜨면서 결과를 화면에 뿌리지만 Skipped step(Validate, FindRepeats & FunctionalAnnotation)을 제외하고 결과가 잘 나왔다. 이번에는 test_run3.sh을 실행해 보았다.

#/bin/sh
#/bin/sh
#../initPipeline -f -m MA_test2.filt2.fna -d test2 -i 1300:1700
#../runPipeline -c metaphyler -p 8 -d test2 -k 31 -f Scaffold,Propagate,Classify -v
#now test contigs
#mv ./test2/Assemble/out/proba.asm.contig test.asm
../initPipeline -f -m MA_test2.filt2.fna -d test3 -i 1300:1700 -c test.ctg.asm
../runPipeline -q -c fcp -p 8 -d test3 -k 31 -v -f FindORFS

결과는 마음에 들게 나왔다.

Glimmer-MG를 설치해야 하는가?

2013년도에 발표된 MetAMOS의 논문에서는 ORF를 찾는 요소 프로그램으로서 MetaGeneMark, FragGeneScan(defaule), 그리고 Glimmer-MG를 소개하였다. 위에서 논의했듯이 FragGeneScan의 실행에 문제가 있으니 MetAMOS 팀(아마도 Todd J. Treangen이 실질적인 리더인 듯)에서는 MetaGeneMark를 사용하라 하였다. 올 여름에 지속적으로 테스트를 하면서 한때 Glimmer-MG(GitHub 참조)를 사용했었다. 이 프로그램은 core 설치로는 깔리지를 않고 단일 유전체 조립을 위한 iMetAMOS 워크플로우에도 속하질 않으므로 python INSTALL.py glimmer-mg라고 타이프하기 전에는 깔리지 않는다. 사실은 deprecated 워크플로우에 속해있기는 하다.

최근에 Glimmer-MG의 설치 과정에서 약간 석연치 않은 점을 발견하였다. RefSeq의 유전체 파일(물론 지금은 유효하지 않은 주소)을 다운로드하는 과정이 포함되어있는 것이 아닌가? 왜 이것을 필요로 할까? 설치 코드를 뜯어보니 Glimmer-MG의 전단계에 필요한 classifier인 Phymm을 설치할 때에 필요하다. 다시 말하자면 install_glimmer.py가 실행될 때 내부에서 phymmblSetup.pl을 불러내는데, 후자의 스크립트가 수록한 RefSeq 파일의 주소가 앞에서도 논의했듯이 이제는 유효하지 않은 것이었다. 차이점이 있다면 all.fna.tar.gz(2.7 GB)가 아니라 all.gbk.tar.gz(7.6 GB)을 필요로 한다는 점이다.

그러면 RefSeq 파일의 download URL을 수정하는 작업을 실제로 해 보자. 설치 스크립트를 열어보면 glimmer-mg-0.3.1.tar.gz(실제 다운로드 주소)을 받아서 압축을 해제한 뒤 install_glimmer.py를 실행하는 구조이다. install_glimmer.py은 다시 phymmbl_installer.tar.gz(실제 다운로드 주소)를 다운받아서 압축을 풀고 그 내부의 phymmblSetup.pl을 실행한다. 생각보다 복잡한 구조이다. 약간의 꼼수를 부려본다. python INSTALL.py glimmer-mg를 실행하면 중간에 RefSeq genomic data 다운로드를 묻는데, 여기에서 n을 입력하여 일시 중단한다. 다음으로 phymm/phymmblSetup.pl을 편집하여 my $targetDir = '/genomes/Bacteria';을 my $targetDir = '/genomes/archive/old_refseq/Bacteria';으로 고친다. 그러고나서 Utilities/glimmer-mg/install_glimmer.py을 열어서 phymmbl 인스톨러를 다운로드하고 압축하는 명령행을 무력화시킨 뒤, 다음을 실행한다. 이번에는 RefSeq genomic data를 다운로드하겠냐는 물음에 'y'를 입력하라.
python ./Utilities/glimmer-mg/install_glimmer.py
파일 다운로드는 무사히 끝났으나 ICM을 만들고 다시 IMM(interpolated Markov model)을 만드는데 너무나 시간이 많이 소요된다. 최초 100개를 처리하는데 약 25분이 걸렸다. 총 5127개의 IMM을 만들어야 하니 아마 이틀은 걸리지 않을까 싶다. 어쩌면 MetAMOS 설치 과정에서 가장 많은 시간이 소요되는 단계가 아닐지 모르겠다. Standard Kraken DB 구축도 아마 소요시간 측면에서 1~2등을 다투지 않을까?

데이터베이스의 업데이트

이미 MetAMOS가 설치 완료된 후 수 개월이 지나서 NCBI의 RefSeq나 Taxonomy 원본 자료가 갱신되었다고 하자. 이를 업데이트하려면 어떻게 해야 될까? 아직은 그 수준까지는 이르지 못했다. 설치 스크립트를 하나씩 뜯어보면서 알아보는 수밖에는...
  • [KronaTools] KronaTools/updateTaxonomy.sh 실행

요소 프로그램들의 업데이트 혹은 추가

설치 스크립트의 실행을 통해 깔리는 third party program은 개발자가 지속적으로 업데이트를 해 나가는 것이 많다. 따라서 프로그램 용법이 바뀌면 Utilities/config/PROGRAM.spec 파일을 바꾸어야 한다. 물론 새로운 프로그램을 추가하는 것도 가능하다. MetAMOS의 개정판이 나오기를 기다리는 것도 좋지만, 이러한 확장성을 철저히 이용하는 것은 더욱 바람직하다. 이것 역시 아직은 직접 체험한 바가 없으니 추후에 작성해 나가도록 한다.
작성자: 시간:

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)