소니 헤드폰 MDR-ZX11-AP의 음질을 다시 생각해 본다

국외 출장길에 충동 구매한 소니 헤드폰 MDR-ZX11-AP. 저가형임에도 불구하고 제값을 다 주고도 모자라 비싸게 구입하였다. 비행기와 버스 안에서 대충 들을 때에는 잘 몰랐는데, 사무실로 돌아와서 원래 쓰던 오디오테크니카 TH-380AV 헤드폰(이것도 좋은 것은 아님)과 비교해 보니 한숨만 나온다. 소리도 훨씬 작고, 답답하고, 선명하지 못하고...

내가 도대체 이것을 왜 샀을까. 더군다나 이것은 통화용 마이크로폰이 달려있어서 4극 단자가 달려있다. 이것을 사무실의 헤드폰 앰프에 꽂으면 접촉이 약간 이상하여 더더욱 듣기에 거북한 소리가 난다. 

이제 이 헤드폰의 용도는 확실히 정해졌다. 오직 바깥에서 휴대폰에 연결하여 음악감상과 통화를 겸하는 것. 차라리 와싸다 닷컴에서 5만원 내외의 적당한 제품을 살 것을...

요즘은 더 이상 싸구려 앰프 만들기에 관심을 쏟지는 않는다. 마지막 트랙 가까이 가면 튀는 CD 플레이어가 고민스러울 뿐이다.

연구개발관리사 자격검정 시험평가가 처음으로 실시된다

연구를 잘 한다는 것은 무엇일까? 창의적이고도 인류가 직면한 여러 문제를 해결할 실마리를 제공할 수 있는 성과를 잘 내는 것이라고 정의할 수 있겠다. 여기에는 사람들을 설득하고, 어느 정도 규모의 연구집단을 이끌고, 연구비 관리를 잘 하는 능력까지도 포함되어 있다. 어떤 사람이 연구를 잘 하는가를 가장 쉽게 평가하려면, 즉 우리 사회에 만연하고 있는 줄세우기를 해 본다면 그 사람의 논문과 특허 등 3P 실적을 보면 된다.

연구 자체와 연구개발 관리는 약간 다르다. 연예인과 매니저가 다른 점을 생각하면 쉽게 이해가 될 것이다. 소속사 없이 혼자서 스케쥴을 챙기고 모든 대외 업무까지 도맡는 1인 연예인도 있기는 하다. 그러나 쉬운 노릇이 아니다.

국가과학기술인력개발원(KIRD)에서 오는 11월 19일 제1회 연구개발관리사 자격검정 시험평가를 실시한다고 한다(대덕넷의 관련기사 링크). 연구개발 기획과 수행·관리, 성과확산 등 전주기 분야와 연구실 안전, 윤리, 보안 등 필수 분야에 대해서 일정 수준 이상의 능력을 인정받으면 자격증을 발급하게 된다.

아직은 이 자격증 취득 여부를 가지고 취업이나 각종 평가에 가산점을 준다는 소식은 들리지 않는다. 앞으로 그렇게 하겠다는 것이 KIRD나 미래부의 의지인 것으로 보이기는 하지만 말이다. 2016년 6월 날짜가 찍힌 국가과학기술심의회 "연구개발서비스 활성화 방안(안)" 공개자료에 따르면 다음과 같은 내용이 있다.

연구개발관리사, 연구장비전문가 등 민간자격제도를 활용하여 실무형 전문인력 양성 연계 및 공인자격으로 확대·발전...'16년 자격시험 시범실시 -> '18년 이후 공인인증자격으로 내실화.

그렇다면 이 자격증이 있는 사람은 연구를 잘 하는 사람인가, 연구개발관리를 잘 하는 사람인가? 머니투데이에 실린 다음의 기사 제목은 오해를 불러일으키기 딱 좋다. 

R&D 역량 검증하는 전문 자격증 나온다.

Science와 Nature에 논문을 자주 싣는 사람과 이 자격증 사이에는 무슨 관계가 있을까? 이건 분명히 잘못된 기사 제목이다. 이 자격증이 분명히 내실이 있는 것이라고 가정하면, 어디까지나 연구개발'관리'에 국한된 것이어야 한다.

또 다른 우려는 이 자격증이 어떤 식으로든 필수적인 요건으로 자리잡게 될 경우 발생할 문제점이 보인다는 것이다. 신설된 제도가 유명무실해지는 것을 막기 위해서 이 자격증을 필수로 하는 일들이 신설될 수도 있다. 예를 들어서 정부연구개발사업을 신청하는 연구책임자는 이 자격증이 있어야 한다거나, 기업 부설 연구소에는 반드시 연구개발관리사 자격증을 취득한 사람이 근무하도록 규정을 만든다거나... 그러면 이 자격증 취득을 위해 교육과정을 준비하고 시험을 주관하는 단체는 확고한 수익 모델을 얻는 셈이 된다. 말하자면 요즘 지나치게 남발되는 민간자격증제도의 나쁜 점을 답습할 우려가 있다는 것이다.

이제는 연구개발도 자격증 시대가 오는가? 학위와 경력 및 그동안의 업적으로도 부족하고 특정 자격증이 있어야만 하는 시대가 올지도 모르겠다. 연구개발관리사, 빅데이터분석사, 연구개발성과확산사, 해외네트워크구축사, 연구부정행위감별사...

Python 3.5.2 설치하고 pyani 실행하기

미생물 유전체의 average nucleotide identity와 관련한 계산 및 그림을 그려주는 도구(pyani)를 설치하려고 보니 python 3이 필요하다. 내 리눅스 컴퓨터에는 CentOS 6.7이 제공하는 python 2.6 및 linuxbrew가 제공하는 python 2.7이 공존한다. 이제 python 3.5는 또 어떻게 설치할 것인가?

루트 권한을 가지고서 소스로부터 설치하는 방법이 있는가 하면, pyenv를 쓰는 방법이 있다. 다른 버전을 그대로 둔 상태에서 평화롭게 공존하도록 설치해야 함이 관건이다.

소스로부터 설치하기

GCC는 여전히 4.4.7이다. linuxbrew가 설치된 상태이므로 su 명령으로 관리자 권한을 획득하면 GCC 5.3.0을, su -로 전환하면 GCC 4.4.7을 쓰게 된다. GCC 4.4.7로는 make test를 통과하지 못했다. 따라서 GCC 5.3.0을 쓰기로 한다. 가장 마지막 단계에서 "make altinstall"을 하는 것이 매우 중요하다. 만약 make install을 해 버리면 기존의 python 명령어를 덮어쓸 것이고, 어떤 문제가 생길지 나도 모른다!

# ./configure --prefix=/usr/local
# make
# make test
# make altinstall
...
Installing collected packages: setuptools, pip
Successfully installed pip-8.1.1 setuptools-20.10.1
# ls /usr/local/bin/python*
/usr/local/bin/python2.7         /usr/local/bin/python3.4m         /usr/local/bin/python3.5m
/usr/local/bin/python2.7-config  /usr/local/bin/python3.4m-config  /usr/local/bin/python3.5m-config
/usr/local/bin/python3.4         /usr/local/bin/python3.5

여기서 궁금증이 발생한다. python3이 관여하는 pip-8.1.1이 도대체 어디에 있단 말인가? 테스트를 해 보자.

# pip -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)
# pip2 -V
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
# pip3 -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)
# exit
$ pip -V
pip 8.1.2 from /home/hyjeong/.linuxbrew/Cellar/python/2.7.12_1/lib/python2.7/site-packages (python 2.7)
$ pip2 -V
pip 8.1.2 from /home/hyjeong/.linuxbrew/Cellar/python/2.7.12_1/lib/python2.7/site-packages (python 2.7)
$ pip3 -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

정말 복잡한 환경이다!

pyani 설치하기

관리자 권한으로 pip3 install pyani를 실행하니 GCC 5.3.0에서는 에러가 발생한다. GCC 4.4.7에서는 잘 설치가 되었다. 도대체 왜 이렇게 복잡한 것인가...  어쨌든 설치는 했으니 실행을 해 보자. average_nucleotide_identity.py가 핵심 스크립트이다. output directory는 이미 존재하는 디렉토리를 지정하면 안된다. 특별히 지정하지 않으면 mummer를 사용하여 순식간에 nucleotide 간의 identity를 계산한다. 가용한 thread를 다 사용하여 계산을 하니 당연한 결과일지도 모른다.

$ average_nucleotide_identity.py -v -i . -o out -g

결과 그림을 보자. 어쩌면 앞으로는 JSpecies를 쓰지 않게 될지도 모르겠다.

pyani는 NCBI tax ID를 이용하여 한번에 유전체 정보를 내려받을 수 있는 스크립트인 genbank_get_genomes_by_taxon.py도 포함하고 있다. ANI 분석을 할 때 매우 유용하게 쓸 수 있을 것이다. 너무 많은 genome 파일을 내려받지만 않을 수 있다면 말이다.

pyenv는 어떻게 하라고?

홈 디렉토리에 .pyenv라는 디렉토리가 있는 것으로 보아 분명히 pyenv를 설치하여 사용한 경험이 있다! 각 파이썬 버전은 ~/.python/version에 설치하도록 되어있다. 소스로부터 /usr/local에 이미 python 3.x를 설치해 버렸으니 pyenv를 경유하여 쓰도록 다시 설치하는 것은 혼란을 줄 여지가 있다. 우선은 그냥 두자!

오른 손목의 통증에서 벗어나기 위한 노력

버티컬 마우스는 큰 어려움 없이 사무실 책상 위의 식구로 자리잡았다. 다른 제조사의 버티컬 마우스는 아직 한번도 경험해 본 일이 없지만, TG 제품은 매우 콤팩트해서 내 손 안에 잘 자리잡는다. 손목의 움직임도 한결 편하고 통증도 줄어들었다.

아울러서 손의 쥐는 힘을 강화하는 것이 손목의 통증을 경감시키는데 도움을 줄 것이라는 생각에 조심스럽게 운동을 시작하였다. 손목을 거의 꺾지 않은 자세로 손의 힘을 강화하는데 도움을 주는 운동으로는 악력기와 푸쉬업바를 이용한 팔굽혀펴기를 선택하였다. 맨 바닥에 손을 대는 것이 아니라 푸쉬업바를 사용하니 손목이 한결 편하다.

최고의 근육운동 팔굽혀펴기 4가지 방법(허핑턴포스트)

운동요법은 대단히 조심스럽게 행해야만 한다. 수개월 전에 손목이 너무 아파서 친구가 운영하는 집 근처 한의원에 찾아가니 손목은 한번 다치면 회복하기 어려우니 되도록 쓰지 말라고 조언하였었다. 의사의 견해에 따르자먼 손목을 쓰는 운동을 잘못 하다간 더 악화될 가능성이 있다.

내가 택한 방법은 단순하다. 스트레칭이나 손 털기를 자주 실시하고, 운동을 하거나 손을 쓸 때에는 손 전체에 힘을 주어서 손목이 좌우로 꺾이지 않도록 유지하며, 필요한 때에는 손목을 가급적 위 아래로만 움직히는 것이다. 운전대를 돌릴 때에도 손에 힘을 세게 주어서 손목이 일자로 펴진 상태에서 움직이도록 하는 습관을 들이고 있다.

무릎 관절이 나빠지거나 척추분리증이 있는 경우 주변부의 근육과 인대를 강화하여 통증을 극복할 수 있다고 들었다. 이러한 원리를 그대로 이용하자는 것이다.

50년 가까이 써 온 기계가 여기저기서 망가지기 시작하는 것은 당연하다. 적절한 관리만이 120시대를 살아가기 위한 유일한 방법이다.

버티컬 마우스로 손목 통증에서 벗어날 수 있을까?

오른손 손목의 통증으로 인해 병원 신세를 진 적이 몇 번 있다. 이를 근본적으로 개선하기 위한 노력은 실제로 거의 하지 않았다. 십중팔구는 하루 종일 컴퓨터 작업을 해서 그런 것으로 생각된다. 손목이 너무 아프면 간혹 손목 보호대를 하고 출근을 하기도 했다.

이번 출장길에 무거운 가방을 끌고 다니다가 손목의 상태가 더욱 악화되었다. 이래서는 도저히 안되겠다 싶어서 우선 마우스를 바꾸어 보기로 하였다. 트랙볼과 버티컬 마우스를 한참 알아보다가 부담없는 가격의 TG-TM137U Healing 모델을 하이마트에서 구입하였다.

랩탑 컴퓨터에 연결하여 처음으로 작동을 시키면서 이 블로그를 쓰는 중이다. 적당히 아담하고 작은 크기이다. 초기 적응이 필요할 듯. 손목에 무리를 주지 않는 마우스를 쓰는 것과 더불어 키보드를 바른 자세로 쓰는 노력도 필요할 것이다. 처음부터 올바른 타자법을 익힌 것이 아니라 그저 마구잡이로 타자를 치는 버릇이 들어버려서 모든 손가락을 골고루 쓰지를 않는 편이다. 네째 손가락과 새끼 손가락을 골고루 사용함으로써 손목의 움직임을 되도록 줄이고, 손목 자체가 꺾이지 않도록 올바르게 손을 배치하는 버릇을 들여 보도록 하자. 아울러서 악력기를 위한 가벼운 손 운동과 손목 스트레칭을 병행해 보겠다.

 하루 사용 후 느낀 점

일반 마우스에 비해 어색함이 그렇게 많이 느껴지지 않는다. 버튼을 더블 클릭할 때 누르는 방향이 평소와는 달라서 약간의 연습이 필요하지만 생각보다 편하고 손목에도 부담이 훨씬 적어진 것으로 느껴진다. 매우 만족스럽다.

CD 플레이어 이후를 생각해 본다

롯데 CD 플레이어 LCD-7500. 1991년 4월 제조.

이런 제목을 달고 보니 마치 수천 장의 오디오 CD를 소장하면서 더 이상 관리가 어려워져서 전부 리핑을 하여 파일 형태로 전환한 뒤 최신의 IT 기법을 이용하여 편리한 음악 감상 생활을 하기 위한 준비로 고민을 하는 것으로 오해를 살 수도 있겠다. 전혀 그렇지 않다. 나는 Go!Classic 사이트에서 내려받은 음원 파일로 구운 것을 포함하여 겨우 수십 장의  CD를 소유하고 있을 뿐이고, 그나마 전체 음악 감상에서 튜너를 소스로 사용하는 비중이 절반을 넘는다. 비록 그 빈도가 높지는 않지만 가끔 음악 CD를 사는 것이 아직도 큰 즐거움인데, 이러한 상황에서 갖는 현실적인 고민은 낡은 CD 플레이어로 요즘 음악을 듣다가 끝 곡 위치에서 튀거나 갑자기 재생을 중단해 버리는 일이 잦아졌다는 것이다. 특히 재생시간이 60분을 넘기는 CD의 경우가 더욱 그러하다.

처음에는 모든 문제의 원인이 픽업에 있다고 생각했었다. 작년 봄에 픽업을 직접 교체한 이후로(링크 1, 링크 2) 이제는 이 장비를 영원히 쓸 수 있을 것으로 자신감을 갖고 있었는데, 엄밀히 말하자면 오랜 시간을 달려서 이제 노후한 모터 자체는 전혀 교체가 되지 않은 것이다. CD 플레이어는 트레이 작동, CD 회전 및 픽업 이송을 위해 총 3개의 모터가 쓰인다고 한다. 픽업이 가장 안쪽(1번 트랙)으로부터 바깥쪽으로 이동하면서 그 위치를 정확히 잡는 것도 중요하지만, 이에 따라서 CD의 회전 속도도 느려져야 한다. 즉 상당한 수준의 제어 메카니즘이 필요한 것인데 달랑 픽업만 교체했다고 해서 어찌 모든 문제가 해결되겠는가? 마지막 트랙 근처, 즉 픽업이 CD의 끝위치에 도달할 즈음에 작동 오류가 발생한다는 것은 결국 그 원인이 픽업 자체가 아니라 일반 사용자가 교체 또는 보수하기 어려운 메카니즘에 존재한다는 것을 강하게 시사한다.

25년을 넘게 달려온 CD 플레이어를 픽업 교체만으로 계속 되살려 사용할 수 있으리라 생각하는 것은 무리이다. 그럼 그 이후를 어떻게 대비할 것인가? 바로 이것이 문제이다. 음악감상 환경이 정말 하루가 다르게 바뀌면서 이제는 블루투스 오디오와 하이엔드 기기 말고는 선택의 폭이 정말 좁아진 것이다. 가능한 대안은 무엇이 있을지 생각해 보았다.

휴대용 CD 플레이어

정말 놀라운 가격(2-4만원)의 휴대용 CD 플레이어를 온라인 마켓에서 쉽게 만날 수 있다. 하지만 요즘 나오는 것들은 휴대성이나 가격 경쟁력에 초점을 맞춘 것이라서 음질을 기대하기 어렵다. 주로 어학 학습용으로 팔린다. 예전의 고급 제품은 디지털 출력을 지원하기도 했다지만 이제는 저가품 말고는 신제품이 나오지 않는다.

저가형 DVD 플레이어

오디오 CD를 재생하지 못하는 DVD 플레이어는 아마 존재하지 않을 것이다. 전용 CD 플레이어와 DVD 플레이어의 오디오 CD 재생 음질에 대한 논란이 꽤 오래전부터 있었다. 만약 DVD 플레이어에 디지털 음성 출력 단자가 있다면 그런 논란에서 벗어날 수 있겠다.

E-IDE DVD/CD-ROM drive 해킹하기*

PC를 업그레이드하면서 나오는 구형 CD-ROM 드라이브에 전원을 달아서 간이형 CD 플레이어를 만드는 것이 잠시 유행인 적이 있었다. 전면에 CD 재생 버튼과 3.5 mm 스테레오 폰잭이 있는 드라이브에 전원(DC 12V 및 5V)만을 연결하여 사용하는 가장 소극적인 방법으로부터, IDE 커넥터에 디스플레이까지 달린 콘트롤러를 달고 S/PDIF 단자로부터 디지털 음성 신호를 빼내는 적극적인 방법에 이르기까지(정보 사례). 인터넷을 뒤지면 마이크로콘트롤러칩을 이용하여 조작장치를 만드는 정보가 나오는데, 요즘은 아예 이베이나 알리익스프레스에서 리모콘까지 포함된 CD-ROM controller를 25-30달러 정도에 판매한다. 이를 활용할 적당한 중고 IDE CD-ROM drive를 구하는 것이 다음 문제가 될 것이다. 8배속을 넘는 고속 드라이브라면 당연히 귀에 거슬리는 회전 소음이 날 것이고, 전원장치 등을 포함하여 케이스를 꾸며 넣으려면 상당히 일이 많아진다. 게다가 S/PDIF 출력이 없이 아날로그 음성 출력만 제공하는 드라이브는 음질을 보장하기 어렵다. 진정한 실력자라면 내부에서 디지털 음성 신호를 빼내는 것도 가능하리라. 모든 E-IDE DVD/CD-ROM 드라이브는 디지털 음성 출력을 제공하는가? 그건 잘 모르겠다. 자작 본능을 충족시킬 가장 적당한 대안이 아닐까 생각한다.

라즈베리 파이 활용

라즈베리 파이에 외장형 ODD를 달아서 CD 플레이어처럼 활용하는 것도 가능할 것이다. 그러나 아직 이에 대한 지식이 깊지 않아서 디스플레이나 키보드를 어떻게 해야 하는지는 잘 모른다. 휴대폰으로 콘트롤하는 방법을 얼핏 본 적도 있다.

정기 건강검진 후기

어제는 매년 의무적으로 받아야 하는 건강검진일이었다. 선택할 수 있는 병원이나 검사 종류의 폭이 예전보다는 넓어졌다. 이제 나이가 나이인지라 대장 내시경을 피해갈 수 없는 시기라는 생각이 들어서 처음으로 이를 선택 검진 항목에 넣었다. 위 내시경을 동시에 받아야 해서 별 주저함 없이 수면 검사를 택했다.

가끔 대장 내시경 검사를 받다가 사고가 일어나는 경우가 있다 해서 걱정을 한 것은 사실이다. 밤새 세장제(쿨프렙산)과 씨름을 하면서 맹물이 이렇게 맛있는 음료라는 것을 처음 깨달았다. 포카리스웨트에 미원과 설탕을 탄 것과 비슷한 맛이었다. 약을 먹기 시작한지 한시간쯤이 지나면서 드디어 화장실을 들락날락... 물을 추가적으로 많이 마신 것이 장을 깨끗이 비우는데 도움이 된 것 같다.

검사 당일. 안그래도 크지 않은 키가 나이가 들면서 조금씩 줄어든다. 시력도 약간 나빠졌다. 그러나 체중이나 비만도는 다 정상 범위이다. 항상 체지방을 조금 줄이고 근육량을 키우라는 말을 듣는데 그게 어디 쉬운 노릇인가.

이윽고 위+대장 내시경 검사 시간. 뒤가 휑하니 뚫리고 덮개가 달린 민망한 바지로 갈아입고 늘 위 내시경을 하던 그 방에 들어가 누웠다. 팔뚝 정맥에 미리 꽂은 주사바늘을 통해 약물이 들어감과 동시에 의식이 사라졌다. 정신을 차리고 보니 회복실이다. 배에 주입한 공기때문에 상당히 불편하다. 한참을 더 누워있다가 정신을 차리고 밖에 나오니 거의 1시간 반이 지나 있었다. 위 내시경을 받던 초창기 시절, 겁이 나서 수면 내시경을 받았었는데 그때는 침대에 실려서 회복실로 나오면서 의식이 돌아오곤 했었다.

검사를 마무리하면서 내시경 결과에 대한 설명을 들었다. 장 청소도 아주 잘 되었고 용종도 하나 없이 깨끗한 상태라서 7년 뒤에 다시 검사를 받으라고 하였다. 용종이 생기는 것은 유전적인 것이니 부모님께 감사하라는 설명과 함께. 고등학생 시절 장염을 심하게 앓은 뒤 남들보다는 화장실 신세를 자주 가는 편인데 - 아마 과민성 대장 증세가 후유증으로 남았으리라 - 어쩌면 장에 변이 머무르는 시간이 상대적으로 짧아서 건강을 해치는 대사물이 생성될 시간이 짧아서 그런지도 모른다는 해석을 내려본다. 말하자면 식당으로 치자면 회전률이 높은 셈이겠다.

커피를 '거의' 끊은지 약 3개월이 지났다. 속이 편해지면서 위장 점막 상태도 회복된 것으로 보인다. 이번에는 위 조직 검사도 하지 않았음을 정말 다행으로 여긴다.

검사를 받은 오후 내내 장이 불편해서 힘들었다. 같이 건강검진을 받을 겸 보호자로 따라온 아내와 함께 근처 식당에서 이른 점심을 먹으러 길을 나섰다가 아랫배가 너무 불편해서 택시를 타고 집으로 돌아왔다. 직장으로 복귀하지 않고 쉰 것이 다행이다.

한 달을 훌쩍 넘긴 이베이 배송

이전 글: 라디오나 만들자

바로 어제 퇴근하기 직전, 이베이 판매자에게 이렇게 시간이 오래 걸려도 물건이 오지 않으니 이제 환불을 해 달라고 요청하려는 찰나 홍콩에서 온 국제우편물이 지금 막 들어왔다는 연락을 받았다. 드디어 배송 사고를 한번 겪게 되나보다 생각했는데 그런 일은 아직 벌어지지 않았다. 이렇게 생긴 물건이다. 위 사진의 시커먼 봉투는 물건이 담겨서 온 봉투이다. 아래 사진은 전선을 안테나 단자에 납땜한 모습이다. 휴대폰 충전기를 연결하면 작동이 된다. 마이크로콘트롤러를 연결하여 세부적인 기능 콘트롤이 가능하다는데 이에 대해서는 충분한 설명이 제공되지 않았다. 이 물건의 정식 명칭은 "DSP(digital audio signal processing) & FM modulation PLL(phase-lock loop) digital stereo FM radio receiver module with serial control"이다.

음질은 컴포넌트 튜너에 비교할 수준은 못된다. 특히 대전에서 잡히는 KBS FM 클래시컬 음악 전용 방송의 신호 강도가 별로 높지 않음을 다시금 느끼게 되었다.

아래에 보이는 두 개의 놉(왼쪽은 'FREQ', 오른쪽은 'VOL')은 가변저항이 아니고 누름 스위치 기능이 있는 로터리 엔코더이다. 무척 단순한 외양을 갖추었지만 로터리 엔코더를 누르면 재미난 기능이 작동한다. 판매자의 홈페이지를 참조하여 이를 정리해 보았다.

먼저 알아야 할 것은 squelch 기능이다. 수신단에 FM 신호가 없을 때 '쉬--'하는 노이즈가 들린다. 이를 차단하는 것이 squelch 회로라고 한다. 이 기기에서는 0-20 범위의 숫자로 squelch threshold를 조정한다. FREQ를 오래 누르면 액정창에 L 10이라 표시가 되는데, 이때 VOL을 돌려서 숫자를 조절하면 된다. 신호가 약한 방송을 들으려면 이 값을 낮추면 된다.

그 다음으로는 campus radio band의 설정이다. 이는 아마도 수신 주파수 대역과 관계가 있는 것으로 생각된다. ON 상태에서는 76-108 MHz를, OFF 상태에서는 87-108 MHz를 수신하게 된다. Campus radio band 설정은... 아아, 도대체 User Setting을 설명하는 판매자의 영어는 무슨 말인지 이해를 할 수가 없다. 몇 번을 다시 읽어도 어떻게 하라는 것인지 알 수가 없다. 설명서 원문은 여기에 있다.

<10>User Set:
This module can be set whether the backlight state to listen to campus radio band, set as follows according to the user's application. Power-off state long press the VOL knob down electrical power LCD display showing open campus radio C0 C1 represents closed campus radio band, set to take effect after the restart. By setting the backlight state is off state press FRE knob key to turn the display backlight Always indicate B1, B0 denotes a backlight turned off 20 seconds after the restart to take effect. Repeat this step to change the setting to switch the state. The factory is set to not open unified campus radio band, backlight turns off 20 seconds without operation.

잘 모르겠으면, 엔코더를 그저 돌리면 된다!

유튜브에서 사용법 확인하기

내가 구입한 것과 거의 비슷한 제품을 설명하는 동영상이 있기에 이를 소개한다. 좌우 다이얼의 위치가 서로 뒤바뀌었고 시리얼 통신을 위한 단자가 없다. 76-87 MHz 범위의 주파수는 전혀 수신할 일이 없으므로 이를 위해서 campus radio band를 OFF로 만들고자 한다면, 볼륨 조절 엔코더를 누른 상태에서 전원을 올리면 액정에 C1(campus radio band ON)이 표시될 것이다. 전원을 끄고 다시 마찬가지의 조작을 하면 이번에는 C0(OFF) 상태가 된다. 위에 인용한 영문으로부터 이러한 설정법을 알아낼 수 있는가?

FREQ 엔코더를 누른 상태에서 전원을 올리면 아마도 액정 백라이트 작동 시간(0 또는 20초)을 바꾸게 되는 것으로 보인다.

MetAMOS under Linuxbrew: Reapr와 FRCbam의 설치 문제

Reapr와 FRCbam은 여러가지의 de novo assembler로 만들어진 결과물을 validation하는데 쓰이는 도구들이다. 만들어진 contig 위에 read를 다시 매핑한 후 다양한 수치를 뽑아낸 뒤 서로 비교하여 최적의 assembly를 고르는 것이 MetAMOS의 Validate process가 하는 일이다.

MetAMOS의 설치 작업 중 가장 까다로운 것이 바로 Reapr와 FRCbam을 설치하는 것이다. Linuxbrew가 제공하는 최신의 빌드 환경(GCC 5.3.0)이 항상 최적은 아닌 것이다. 설치 스크립트를 열어보면 이 두 가지의 프로그램을 까는 일이 얼마나 복잡하게 수행되는지를 알 수 있다. 수 일 동안 엎치락뒤치락하다가 경우 조건을 잡고 최종 테스트를 실행하는 중이다.

Reapr는 Linuxbrew에서 INSTALL.py를 실행하는 것만으로도 별 문제없이 설치가 된다. 그러나 FRCbam은 스토리가 여간 복잡한 것이 아니다. INSTALL.py, 즉 MetAMOS 설치 스크립트에 나온 다음의 소스파일(요즘은 여기에서 다운로드가 안되어서 예전에 받아둔 것을 사용)은 도저히 제대로 바이너리가 만들어지질 않는다.

ftp://cbcb.umd.edu/pub/data/metamos/FRC_align-master.zip (version 1.0)

그래서 이를 별도로 받아서 단독으로 빌드해 보려고 하면 여기에서도 난관에 부딪힌다. GCC version을 끔찍하게도 가리기 때문이다. 구글에서 FRCbam을 찾으면 GitHub의 version 1.3이 나오는데, 이는 GCC 4.4.7에서 아주 쉽게 빌드된다(INSTALL.py에서 나타나는 복잡함이 대폭 줄어들었음). 그런데... 옵션이 몇 개 바뀌어서 정작 MetAMOS 실행에서는 에러가 발생하는 것이다. Validate 과정에서 --pe-min-insert 라는 옵션을 보내는데 FRCbam version 1.3 실행파일은 사용법이 틀렸다는 에러 메시지를 토해내는 것이다. FRCbam의 c++ 소스 코드를 고쳐야 하나? 혹은 validate 기능을 불러오는 파이썬 스크립트를 고쳐야 하나? 좌절감이 극도에 달했다.

온갖 고생을 한 끝에 FRCbam v1.0을 단독으로 빌드하는데 성공하였다. 이렇게 만들어진 바이너리 파일(FRC)을 Utilities/cpp/Linux-x86_64/FRCbam/bin/에 복사해두면 된다. 그 과정을 나열하면 다음과 같다. Linuxbrew나 devtools에 의존하지 않고 CentOS 6.7에서 기본 제공하는 GCC 4.7.1을 쓴다는 것이 키 포인트!

1. (GCC 4.7.1; 수퍼유저 권한) boost-1.54.0을 소스에서부터 설치한다. 설치 위치는 /opt/local로 하였다(./bootstrap.sh --prefix=/opt/local; ./b2 install)
2. (GCC 4.7.1; 수퍼유저 권한일 필요 없음) FRCbam v1.0의 압축을 풀고 INSTALL 파일에 적힌 그대로 실행하면 src 아래에 FRC 바이너리가 생긴다.
3. FRC 바이너리를 제 위치에 복사한다. 각 단계가 정확히 어떤 커맨드로 실행되는지 알고 싶으면 $outDir/Logs/COMMANDS.log 파일을 참조하면 된다.

test_ima.sh 스크립트를 실행해 보았다. 화면으로 FRCBAM 스코어가 나오는 것이 보인다. 

*** metAMOS assembler velvet.37 scores:  LAP:-13.3038811606 ALE:-914695.701821 CGAL:-1.4167e+06 SNP:-1 FRCBAM:-4 ORF:203 REAPR:97.72 N50:159698

그동안 한 고생을 생각하면 눈물이 다 날 지경이다! Validate 결과 화면을 보자.

Abundance, Annotate, FunctionalAnnotation 모두 어여쁜 Krona plot을 나타내고 있다. 

단독 설치 말고 어떻게 해서든 INSTALL.py내에서 FRCbam을 설치해 볼까?(실패)

다음은 INSTALL.py 내에서 boost 라이브러리의 설치 여부를 체크하는 곳이다. boost를 기본 조건으로 설치하면 /usr/local에 위치하게 되어 다음의 코드가 이를 인식하지 못하고 boost의 다운로부터 빌드까지를 자체적으로 실시한다. 이러한 빌드 과정이 외견상으로는 매끄럽게 진행되었어도 FRC 바이너리가 실행 가능한 형태로 만들어지는 것을 아직 제대로 본 적이 없었다.

if os.path.exists("/opt/local/lib/libboost_system-mt.a"):
   os.environ["LDFLAGS"]="-L/opt/local/lib -lboost_system-mt"
elif os.path.exists("/opt/local/lib/libboost_system.a"):
   os.environ["LDFLAGS"]="-L/opt/local/lib -lboost_system"
elif os.path.exists("/usr/lib/libboost_system-mt.a"):
   os.environ["LDFLAGS"]="-L/usr/lib -lboost_system-mt"
elif os.path.exists("/usr/lib/libboost_system.a"):
   os.environ["LDFLAGS"]="-L/usr/lib -lboost_system"
else:
   # install boost ourselves (고난의 시작...)

이제 boost를 /opt/local에 설치하였으므로 위 코드의 첫번째 if 문에서 틀림없이 걸리게 되어있다. 마지막 테스트라 생각하고 다시 고난의 여정으로 들어가 본다. 위에서 만든 FRC 디렉토리를 _FRC로 잠깐 이름을 바꾸어놓고  python INSTALL.py frcbam을 실행해 보았다. 이번에는 GCC 4.7.1이 아니라 Linuxbrew의 GCC 5.3.0을 사용하는 것이다. 

결과는? 컴파일 오류가 발생한다. 더 이상의 시도는 의미가 없는 것으로 판단한다.

De novo assemblers - 아직 끝이 난 것이 아니다!

open MPI가 필요한 일부 de novo assembler의 설치 상태가 완벽하지 않다. open MPI 자체가 제대로 설치된 것인지, 이를 구동하려면 커널 모듈이 올라가야 한다고 들었는데 과연 제대로 작동하는 것인지를 좀 더 공부해야 한다. INSTALL.py에서는 mpirun 바이너리가 $PATH에 있는 것만을 점검하는 것처럼 보이지만, 이는 어쩌면 나의 오해인지도 모른다.

$ rpm -qa | grep openmpi
openmpi-1.10-devel-1.10.2-2.el6.x86_64
openmpi-1.4-psm-1.4.3-5.el6.x86_64
mpitests-openmpi-3.2.4-2.el6.x86_64
openmpi-1.8-1.8.1-5.el6.x86_64
openmpi-1.4-1.4.3-5.el6.x86_64
openmpi-1.8-devel-1.8.1-5.el6.x86_64
openmpi-1.10-1.10.2-2.el6.x86_64
openmpi-1.5.3-psm-1.5.3-5.el6.x86_64
openmpi-1.5.3-1.5.3-5.el6.x86_64

뭐가 이렇게 많이 깔린 것일까??

INSTALL.py 스크립트에서 mpirun 커맨드가 존재하는지 확인하는 프로그램은 ABySS, mpicxx가 존재하는지 확인하는 프로그램은 ray이다. MPI와 어떤 관계가 있는지는 모르나 Celera Assembler와 MaSuRCA도 아직 제대로 빌드되지 않았다. 이는 마지막으로 남은 숙제이다.

ABySS는 제대로 설치가 되었고 실행도 된 흔적이 있지만 결과물이 없다. 아마도 샘플 데이터가 적합치 않아서 결과까지는 이끌어내지 못한 것으로 생각된다. Ray는 open MPI의 mpirun을 $PATH에 등록한 후(export PATH=^Csr/lib64/openmpi/bin:$PATH) GCC 4.7.2 환경(devtoolset-1.1)에서 INSTALL.py를 실행하니 비로소 설치가 되었다. MaSuRCA는 여전히 잘 모르겠고, 역시 설치가 어려운 Celera Assembler는 viersion 8.1의 바이너리 패키지를 따로 받아서 MetAMOS 설치 디렉토리에 복사하면 되지 않을까 생각하고 있다.

MetAMOS under Linuxbrew (CentOS 6.7)

MetAMOS란?

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

• [논문] MetAMOS: a modular and open source metagenomic assembly and analysis pipeline. Genome Biol. 2013 14(1):R2
• [iMetAMOS workflow 논문] Automated ensemble assembly and validation of microbial genomes. BMC Bioinformatics 2014 15:126
• [다른 연구 그룹의 논문] Extending MetAMOS - new methods and new integrations. PeerJ PrePrints 2016 4:e1706v1 
• GitHub 
• v1.5.rc3 README(2014)
• [User gude] link 1 link 2(PDF)

설치를 위한 주의 사항

파이썬 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의 개정판이 나오기를 기다리는 것도 좋지만, 이러한 확장성을 철저히 이용하는 것은 더욱 바람직하다. 이것 역시 아직은 직접 체험한 바가 없으니 추후에 작성해 나가도록 한다.