from lvaruzza.com - Leonardo Varuzza`s Site

Transcrição

Introdução à análise de dados de sequenciadores de nova geração
Versão 2.0.1
Leonardo Varuzza
Abril 2013
2
Sumário
1 Introdução
1.1 O que é NGS . . . . . . . . . . . . .
1.2 Como funciona o NGS . . . . . . . .
1.2.1 Preparo da amostra . . . . .
1.2.2 Amplificação de biblioteca . .
1.2.3 Sequenciamento . . . . . . .
1.2.4 Ion Torrent . . . . . . . . . .
1.2.5 SOLiD . . . . . . . . . . . . .
1.3 Aplicações do NGS . . . . . . . . . .
1.3.1 Ressequenciamento genômico
1.3.2 Target Sequencing . . . . . .
1.3.3 RNA Seq . . . . . . . . . . .
1.3.4 Sequenciamento denovo . . .
1.3.5 Metagenoma . . . . . . . . .
2 Arquivos de Sequência
2.1 Fasta e FastQ Files . . . . . . . . .
2.1.1 Fasta format . . . . . . . .
2.1.2 FastQ format . . . . . . . .
2.2 SFF File . . . . . . . . . . . . . . .
2.2.1 Converter arquivo SFF para
2.3 Unmapped BAM . . . . . . . . . .
2.4 XSQ Format . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
7
8
8
9
12
12
13
13
14
14
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
Fasta ou FastQ .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
16
17
18
18
21
21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
26
26
28
30
30
31
32
33
34
34
35
35
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Mapeamento de Sequências
3.1 SAM e BAM Files . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Estrutura do arquivo SAM . . . . . . . . . . . . . . .
3.1.2 BAM File . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Samtools . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Picard . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Mapeando os reads com o TMAP . . . . . . . . . . . . . . . .
3.2.1 Criando o índice . . . . . . . . . . . . . . . . . . . . .
3.2.2 Mapeando os reads . . . . . . . . . . . . . . . . . . . .
3.2.3 Exemplo: Mapeando os reads de E. coli com o TMAP
3.2.4 Mapeando dados de Long Mate Pair . . . . . . . . . .
3.3 Bowtie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Utilizando o Bowtie 2 . . . . . . . . . . . . . . . . . .
3.3.2 Utilizando o Bowtie 2 com o Ion Torrent . . . . . . . .
3.4 Visualizando arquivos BAM com o IGV . . . . . . . . . . . .
3.4.1 Importanto o genoma de referência . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Arquivos de Anotação de Genomas
4.1 BED Formats . . . . . . . . . . . . . . . . . .
4.2 Formatos GFF e GTF . . . . . . . . . . . . .
4.3 Gerando arquivos de anotação . . . . . . . . .
4.3.1 Obtendo anotações do UCSC Browser
4.4 Manipulando arquivos BED . . . . . . . . . .
4.4.1 Extrair sequências da regiões . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
41
43
43
5 Detecção de Variâncias
5.1 VCF Files . . . . . . . . . . . . . . . . . . .
5.1.1 Manipulando arquivos VCF . . . . .
5.1.2 Indexando as variantes . . . . . . . .
5.2 Utilizando o samtools para detectar SNPs .
5.2.1 Gerando um arquivo consenso . . . .
5.3 Utilizando o GATK . . . . . . . . . . . . .
5.3.1 Chamando Variantes no GATK . . .
5.3.2 Anotando as variantes com o dbSNP
5.4 Utilizando Ion Varriant Caller . . . . . . . .
5.5 Anotando os SNP’s com o snpEff . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
47
47
48
48
49
49
50
50
51
6 Montagem denovo
6.1 Montando o genoma com o Mira . . . . . . . . . . . . . . . . . . . . .
6.1.1 Montando uma biblioteca de fragmentos utilizando o Mira 3.4 .
6.1.2 Montando uma biblioteca de mate-pair utilizando o Mira 3.4 .
6.1.3 Fazendo uma montagem mista com o Mira 3.4 . . . . . . . . .
6.1.4 Fazendo uma montagem mista com o Mira 3.9 . . . . . . . . .
6.1.5 Interpretando os resultados . . . . . . . . . . . . . . . . . . . .
6.1.6 Comparando a montagem com uma referência . . . . . . . . . .
6.1.7 Visualizando a montagem no Tablet . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
56
57
57
58
59
60
61
7 Apêndices
7.1 Ordem dos genótipos
7.2 Pileup format . . . .
7.3 Samtools VCF file .
7.4 Script para converter
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
65
66
67
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
os nomes dos cromossomos em um arquivo VCF
4
Capítulo 1
Introdução
1.1
O que é NGS
Sequenciadores de DNA são equipamentos que leem uma amostra de DNA e geram um arquivo eletrônico
com simbolos que representam a sequência de bases nitrogenadas – A, C, G, T – contidas na amostra. O
primeiro método popular de sequenciamento da DNA foi o de terminação de cadeia de Sanger, publicado
em 1977. Em 1986 foi lançado o primeiro sequenciador automático de DNA, o ABI 370, e em 1998, o
primeiro sequenciador de eletroforese capilar, o ABI 3700. Com a automatização foi possível realizar
grandes projetos de sequenciamento, como o genoma humano, do camundongo e outros. Para realizar
esses projetos foram montados grandes centros com dezenas de máquinas instaladas e ao custo de bilhões
de doláres.
O sequenciamento de nova geração – Next Generation Sequencing, em inglês, ou simplemente NGS
– são processos de sequenciamento de DNA que utilizam metodologias diferentes da de Sanger, com o
objetivo de acelar e baixar o custo do processo de sequênciamento. Apesar de se diferenciarem consideravelmente entre sí todos os sequenciadores de NGS se baseiam no processamento paralelo massivo de
fragmentos de DNA. Enquanto que um sequenciador de eletroforese processa, no máximo, 96 fragmentos
por vez, os sequenciadores de nova geração podem ler até bilhões de fragmentos ao mesmo tempo.
Na figura 1.1 vemos a evolução do custo por megabase sequenciada. Nota-se um primeiro decrésimo
em 2004, ano do lançamento do sequenciador 454 da Roche e um decrésimo mais acentuado a partir
de 2006 e 2007, anos em que foram lançados os sequenciadores de nova geração da Illumina e da Life
Technologies. No gráfico, vemos também qual seria a redução de custo, se a tecnologia de sequenciamento
tivesse evoluido segundo a lei de Moore[23]. Vê-se que a evolução do sequenciamento de DNA foi muito
mais acelerada do que dos processadores de computadores. A implicação disso é que os sequenciadores
evoluiram muito mais rápido do que os computadores que analisam os dados gerados, daí a necessidade
computacional para lidar com os dados gerados ter se tornado muito maior do que há 10 anos.
5
��
��
��
��
��
��
��
��
��
��
��
��
��
��
��
��
��
��
��
Figura 1.1: Evolução do custo de sequenciamento por megabase. Fonte: http://www.genome.gov/
sequencingcosts/.
Apesar da redução impressionante no custo por megabase, o custo por reação, também chamdado do
custo de apertar o botão start, ainda é bastante alto, da ordem de dezenas de milhares de dólares. Ou
seja, ampliou-se muito a capacidade dos sequenciadores, permitindo até o sequenciamento de mais de um
genoma por corrida, mas sem reduzir muito o custo de operação do equipamento. Um fator limitante na
redução desse custo é o uso de reagentes caros, como bases marcadas por fluoróforos. No final de 2010,
foi lançado o PGM, da Ion Torrent, o primeiro sequenciador a detectar a incorporação dos nucleotídeos
através de um semicondutor, reduzindo, dessa forma, a complexidade do equipamento e o custo da reação
de sequencimento.
1.2
Como funciona o NGS
Cada tecnologia de sequenciamento possui uma estratégia diferente, mas em geral podemos identificar etapas comums entre todos os sequenciadores1 : preparo da amostra, amplificação da biblioteca e
sequenciamento.
1.2.1
Preparo da amostra
Primeiro o DNA é fragmentado por um processo químico, mecânico ou enzimática. Cada um desses
fragmentos é chamado de template. Não importa qual o método de fragmentação escolhido, é importante
que ele quebre o DNA de maneira aletória, de forma que todo o genoma seja coberto de maneira o mais
uniforme possível2 .
Após a fragmentação, adaptadores, sequências artificiais conhecidas, são incorporados ao template.
Nessa etapa é possível combinar diferentes amostras em uma mesma reação de sequênciamento através
do uso de adaptadores com uma pequena parte , normalmente 5 ou 10 bases, diferente. Depois de ligados
esses adaptadores, as amostras são misturadas, amplificadas e sequenciadas juntas. Após isso, no processo
de sequênciamento, essa parte do adaptador é lida e as amostras são separadas computacionalmente.
Um outro tipode de biblioteca são as de Long Mate-Pair[28], ou LMP. Nesse caso, são gerados
tamplates maiores, da ordem de algumas kilobases. São ligados adaptadores complementares nas pontas
do template e ele é circularizados. Em seguida é feita uma digestão enzimática que gera um único
fragmento com as duas pontas do template separadas adaptador interno (ver figura 1.2). Apesar de ser
um processo mais trabalhoso para o preparo de uma bibliotecas simples de fragmentos, o LMP permite a
detecção de variações estruturais em projetos de ressequenciamento e de geração de scaffolds em projetos
de sequenciamento denovo.
1 Nos últimos anos foram propostas tecnologias que tentam eliminar a etapa de amplificação, sequenciando diretamente
uma única molecula de DNA, porém todas as tecnologias propostas sofreram de problemas de baixa acurácia e baixo
throughput.
2 Uma excessão à essa regra é o sequenciamento de amplicons, nesse caso o objetivo é sequenciar pequenas regiões que
tem exatamente o tamanho da leitura gerada pelo sequênciador
6
Figura 1.2: Processo da amostra de Long Mate Pair.
Um artefato que pode surgir nessa etapa são as duplicações de reads causadas por artefatos de PCR.
Esses artefatos podem gerar distorções na cobertura do genoma e impactar as análises de variações do
genoma ou de expressão do transcriptoma. Por conta disso, as pipelines de análises normalmente possuem
uma etapa em que os reads duplicados são marcados, e consequentemente ignorados nas análises finais.
1.2.2
Amplificação de biblioteca
A amplificação de bibliotecas tem como objetivo gerar em um pequeno espaço físico milhares de cópias
de cada fragmento de DNA produzido na etapa de preparo da amostra. O objetivo dessa amplificação é
aumentar a fonte de sinal luminoso para a maioria dos sequenciadores, e iônico no o caso do Ion Torrent,
que será detectado na etapa de sequenciamento.
O primeiro processo de amplificação desenvolvido para esse propósito foi o PCR de emulsão. Nele
são criados milhões de micro reatores em uma emulsão de óleo. Esses reatores contêm todos os reagentes
necessários para uma reação de PCR e pequenas esferas (também chamdas de beads ou de IonSpheres)
cobertas com a sequência complementar ao adaptador. Esses fragmentos, servem para fixar os clones do
template na esfera e também como primer para a reação de PCR. Ao final do processo a esfera pode
estar em quatro estados:
1. Caso ideal: Um único fragmento foi incorporado à uma única esfera.
2. Beads policlonais: Múltiplos fragmentos foram incorporados a uma esfera.
3. Empty bead: Nenhum fragmento foi incorporado à esfera.
4. Multiple beads: Mais de uma esfera estava presente no micro reator.
O caso de Multiple beads é controlado pelo tamanho do reator, de forma que caiba somente uma esfera
por reator. As empty beads são eliminadas através de uma operação de enriquecimento para beads com
template incorporado. Por fim, as beads policlonais são controladas por meio de um processo estatístico,
que segue uma distriuiçãode Poisson. Basicamente temos muito mais beads do que templates . Por
exemplo, se tivermos 10 vezes mais beads do que templates, espera-se que somente 0,47% das beads
sejam policlonais. Claro que o efeito secundário é que 90% das beads estejam vazias, porém essas beads
são eliminadas por meio do processo de enriquecimento.
O principal fator que afeta a etapa de amplificação é a quantificação do DNA. Se o DNA for subquantificado, ou seja, existe mais DNA na amostra do que o reportado, o resultado vai ser um aumento da
quantidade de beads policlonais. Por outro lado, se o DNA for sobrequantificado, ou seja, se existe menos
DNA do que o reportado, o resultado vai ser uma quantidade muito pequena de beads com fragmentos.
Na tabela 1.1 vemos a porcentagem esperada de beads policlonais e empty beads, se tivermos uma relação
1 para 1 entre beads e fragmentos esperasse que mais de 26% das beads sejam policlonais.
7
Razão
10
5
4
3
2
1
Policlonal (%)
0.47
1.75
2.65
4.46
9.02
26.4
Empty (%)
90.5
81.9
77.9
71.7
60.7
36.8
Tabela 1.1: Relação entre a razão beads/fragmentos, a probabilidade de beads policlonais e a probabilidade de empty beads.
1.2.3
Sequenciamento
O sequenciador é um instrumento que executa uma série de reações químicas. Estes geram sinais que são
detectados e determinam a sequência de bases template se está sendo analisado. A seguir, vamos mostra
o processo de sequenciamento de dois intrumentos que têm abordagens completamente diferentes: o Ion
Torrent e o SOLiD.
1.2.4
Ion Torrent
A maioria dos sequenciadores utiliza uma DNA polimerase para gerar a fita complementar ao template ,
bases marcadas por fluoroforos, e câmeras a detecção. O Ion Torrent é diferente pois a detecção é feita
diretamente. A reação de polimerização gera naturalmente um um H +3 , ou seja, um próton, que altera
o pH do meio. Essa alteração do pH é detectada por um transistor ISFET[1] e convertida em um sinal
elétrico (figura 1.3).
Figura 1.3: Reação de incorporação de uma base pela polimerase.
Outro ponto importante para determinar a sequência é sincronizar a polimerase com a detecção,
tanto no Ion Torrent quanto no 454 essa sincronização é feita pelo controle do tipo disponível para a
polimerase. Por exemplo, suponha que o início do fragmento que se deseja sequenciar seja AGT e que o
sequenciador disponiblize uma certa quantidade de dTTP. A polimerase vai fazer o pareamento do A com
o T e o sinal vai ser detectado pelo transitor ISFET. Para continuar a reação, a polimerase necessita de
um dCTP, porém esse reagente não está disponível e, portanto, a reação para e a leitura da incorporação
é feita. Em seguida, ocorre uma lavagem, e a base seguinte é injetada, e assim por diante em uma série
3 A reação de polimerização também gerar um fosfato e esse é o caminho de deteção utilizado pelo 454, com a diferença
que a emissão do fosfato não é detectada diretamente, mas indiretamente através da ativação de uma luciferase que gera
luz
8
de fluxos. Podemos ver na figura 1.4 uma representação dos sinais detectados pelo sensor de um único
poço. É essa informação de intensidade de sinal que é convertida depois na sequência de bases.
Figura 1.4: Flowgram da sequência AATCTTCGT...
Uma questão relevante para os sequenciadores que utilizam fluxos de dNTP’s são os homopolímeros, sequencias contínuas de bases iguais como AAAA, CCCCC e etc4 . Nesse caso, todas as bases do
homopolímero vão ser incorporadas em um único fluxo. Felizmente, o sensor ISFET tem uma resposta
bastante linear; portanto, se um A tem um sinal x, um AA vai ter um sinal aproximadamente 2x, e
assim por diante. Na prática, é possível detectar com boa acurácia homopolímeros de até 6 bases.
O último elemento importante, e que diferencia os sequenciadores da nova geração em relação à
anterior, é o paralelismo da reação e da detecção. No Ion Torrent esse paralelismo é obtido pelo uso de
chips de silício. Utilizando o processo CMOS, o mesmo utilizado na fabricação de chips de computador
ou sensores de câmeras digitais, são construídos milhões de poços microscópicos um pouco maiores do
que as esferas com fragmentos de DNA, de forma que, em cada poço, tenha somente uma esfera. No
chip estão também os transitores IsFET que fazem a detecção da mudança de pH, ou seja, cada poço
possui o seu próprio “pH-gâmero” para fazer a detecção do sinal[29].
1.2.5
SOLiD
A sigla SOLiD significa Sequencing by Ligation and Detection e descreve bem o processo de sequenciamento utilizado pelo instrumento. Ao invés de utilizar uma polimerase e detectar a incorparação de cada
uma das bases, o SOLiD utiliza octâmeros marcados com fluoróforos para identificar a sequência alvo.
As primeiras 5 bases da probe garantem a especificidade da ligação da probe com o template, enquanto
que as 3 útimas são inosinas que anelam de maneira inespecífica. Conectado à última, inosina temos o
fluróforo que gerará o sinal luminoso a ser detectado pelo sequenciador (ver fig 1.5).
Fluoróforo
Probe
n1 n2 n3 n4 n5 x x x
Figura 1.5: Estrutura da probes utilizadas pelo SOLiD
No SOLiD, assim como no Ion Torrent, cada fragmento é amplificado milhares de vezes na superfície
de uma bead5 . Essas beads são então depositadas e fixadas em uma lâmina de vidro. É muito importante
ter essa fixação, porque sabemos que o sinal luminoso que será gerado pelo processo de sequenciamento
está vindo da mesma bead (ou seja, da mesma população de clones geradas de um template) por meio
das coordenadas do ponto luminoso na lâmina.
4 Notem
que microsatélites com mais de uma base na repetição, como ACACAC, não são homopolimeros
uma novo modelo do SOLiD, o 5500W, que não utiliza beads. A amplificação dos templates é feita diretamente
na lâmina.
5 Esses
9
A reação de sequenciamento ocorre para cada um dos milhares de clones em cada uma das centenas
de milhões de beads depositadas na lâmina. As etapas dessa reação são, de maneira simplificada, as
seguintes:
1. Na etapa de construção de biblioteca, é adicionado um primer em cada extremidade de cada fragmento, chamados de P1 e P2 . No processo de sequenciamento é adicionado um primer complementar
à P1 , chamado de PA . A última base desse primer alinha com a última base de P1 (fig 1.6 A)
2. É adicionado um pool equimolar de probes. Como temos 4 bases diferentes e uma estrutura de 5
bases mais 3 inosinas, temos portanto 4ˆ5 = 1024 combinações diferentes de probes. As probes vão
se anelar ao longo do template. Após o anelamento, é adicionada uma ligase, que vai fixar somente
a probe que estiver ao lado de uma ponta 506 . Após a fixação pela ligase ocorre uma lavagem e
todas as probes não fixadas são removidas (fig 1.6 B)
3. É feita a leitura do floróforo. As inosinas, as três últimas bases da probe, são removidas junto com
um floróforo, criando assim uma ponta 50 livre para fazer a ligação da próxima probe (fig 1.6 C)
4. É feita uma nova incorporação de probes e o processo se repete (fig 1.6 D)
A. Primer se liga ao template
primer
C. As 3 últimas bases da probe (as inosinas) são
removidas junto com a probe.
primer
5’
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Template
Template
D. Uma nova probe é incorporada e o processo
se repete.
B. Primeira probe anela ao template e
fluóroforo é lido.
Probe
primer
5’
primer
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Probe
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Template
Template
Figura 1.6: Algumas etapas do processo de sequenciamento: ligação do primeiro primer.
A incorporação de probes é repetida 5, 7, 10 ou 15 vezes, dependendo do tamanho desejado de leitura.
Terminado esse ciclos o sistema é aquecido e a fita complementar ao template que foi gerada denatura e
é eliminada. É então incorporado um novo primer, chamado de PB , que alinha uma base a esquerda de
PA . Todo o processo de incorporação de probes é repetido, mas sempre com uma base à esquerda (fig
1.7). Na tabela 1.3 vemos a relação entre primer, ciclo e bases lidas. Vemos que a cada ligação de probe
duas bases são lidas e que cada base é lida por duas probes diferentes. Por exemplo, a base s1 é lida
pelo ciclo 1 do PA e pelo ciclo 2 do PB . Essa construção é chamada de Two Bases Encoding ou 2BE7 ,
e permite que se faça depois a correção de erros que aumenta a acurácia do processo de sequenciamento
e esta é a principal característica do SOLiD. Vale a pena também resaltar que na segunda ligação, a
última base do primer P1 é sequenciada, isso é muito importante para fazer depois a decodificação das
cores para bases.
probes consecutivas não ligam porque na extremidade 50 da probe tem o floróforo, que impede a ligação 50 –30 .
também uma codificação alternativa chamada de Four Bases Enconding, ou 4BE, que é opcionalmente utilizada
para fazer uma segunda correção de erros chamada de Exact Call Chemistry ou ECC.
6 Duas
7 Existe
10
0
1
2
3
Cor
Azul
Verde
Amarelo
Vermelho
Fluoróforo
FAM
Cy3
TXR
Cy5
Tabela 1.2: Codificação das cores em números.
Pelo processo de sequenciamento, cada probe 2 de cada 5 bases cobertas por ela, para cobrir todas as
bases duas vezes, temos que utilizar 5 probes, que se alinham em posições diferentes de P1 e permitem
que se cubra todo o fragmento8 . Veja a figura 1.8.
Primer
PA
PA
PA
...
PB
PB
PB
...
Ciclo
1
2
3
...
1
2
3
...
Bases Lidas
s1 s2
s6 s7
s11 s12
...
p0 s1
s5 s6
s10 s11
...
Tabela 1.3: Leitura de bases pelas probes do SOLiD
O resultado do sequenciamento é codificado em números de acordo com a tabela 1.2. A relação entre
as duas primeiras bases da probe, n1 e n2 , e a cor do fluróforo é dada pela tabela 1.4. Essa tabela
tem diversas propriedades interessantes: ela é simétrica e nenhuma cor se repete na mesma linha ou na
mesma coluna (como em um jogo de Soduko). Por causa dessas propriedades temos que, se soubermos
a primeira base do par e a cor fica determinada a segunda base. Suponhamos que a primeira base do
par seja um T, se a cor lida pela probe for verde, a segunda base é, portano, um G. Como o primeira
probe do primer PB lê a última base do adaptar P1 , que é conhecida, podemos portanto descobrir qual
é a primeira base da leitura. Tendo a primeira base da leitura e a segunda cor, podemos descobrir a
segunda base, e assim por diante. Podemos pensar nas cores como transformações entre bases, e que se
essas transformações forem encadeads, podemos gerar todas as bases da leitura.
Suponha que a última base de P1 seja um T, e que a seguinte sequência de cores tenha sido obtida:
3 1 3 1 0 2 . Se consultarmos a tabela 1.2, temos que T na primeira base com 3 gera um A, portanto
a primeira base da nossa sequência é um A, o que nos gera o seguinte resultado intermediário:
A1 3 1 0 2
Vendo agora, a combinação de A com 1 gera um C, e o nosso segundo resultado intermediário é:
AC 3 1 0 2
Continuando a aplicar as transformações chegamos aos seguintes resultados:
ACG 1 0 2
ACGT 0 2
ACGT T 2
ACGT T C
Portanto, a sequência T313102 codificada em color space representa a sequência ACGTTC em base
space.
8 Pela construção das probes sequenciaríamos também as 5 últimas bases de P , o que não é interessante. Por isso, após
1
o primer PB , é adicionado um espaçador que desloca a posição inicial do sequenciamento 5 bases para frente.
11
C. Novamente as inosinas e o fluóroforo são
removidos.
A. Um novo Primer se liga ao template uma
posição para dentro do primer.
primer
5’
primer
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Template
Template
D. E o processo segue, sempre com uma base
deslocada à esquerda.
B. Como no primer anterior a probe se anela,
porém deslocada uma base à esquerda.
primer
5’
Probe
Probe
primer
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Template
... p-2 p-1 p0 s1 s2 s3 s4 s5 s6 s7 ...
Template
Figura 1.7: Algumas etapas do processo de sequenciamento: Ligação do segundo primer.
n1
n2
A
C
G
T
A
0
1
2
3
C
1
0
3
2
G
2
3
0
1
T
3
2
1
0
Tabela 1.4: Codificação de bases para cores
1.3
Aplicações do NGS
O número de aplicações do NGS é ilimitado. Qualquer coisa que possa ser transformada em DNA pode
ser sequenciada utilizando o mesmo protocolo. Por isso, se alguém quiser criar uma nova análise, basta
modificar a etapa de preparo de biblioteca e de análise e teremos uma nova aplicação. Mesmo assim,
existe um grupo de aplicações que é mais utilizado pela comunidade científica.
1.3.1
Ressequenciamento genômico
Projetos de ressequenciamento têm como objetivo descobrir diferenças entre o genoma de referência e o
genoma de interesse. Os projetos de ressequenciamento normalmente buscam encontrar diferenças entre
o genoma de uma pessoa saudável e o genoma de uma pessoa com alguma doença, como o câncer ou uma
doença hereditária. O ressequenciamento também tem aplicações agropecuárias: pode-se utiliza-lo para
entender a diferença entre genomas de raças de animais, cultivares de plantas ou isolados de bactérias.
O resultado de um projeto de ressequenciamento é a lista das variantes detectadas. Tendo em mãos
essa lista, o pesquisador pode compará-la com os genes anotados do organismo para tentar entender a
relação entre genótipo e fenótipo. Um parâmetro importante para o ressequenciamento é a cobertura
média do genoma, ou seja, quantas vezes em média cada base do genoma foi coberta. Suponha um
genoma de 3 Gbp: para ter uma cobertura de 20× é preciso gerar 60 Gbp de dados. Para detectar
variantes germinativas é recomendada uma covertura entre 20× e 30×, porque essas variantes vão ter
uma frequência em torno de 100% para mutações homozigotas e 50% para variações heterozigotas. Já
para detectar variantes somáticas, é necessária uma cobertura maior, porque essas variantes ocorrem
12
0
P1
5
10
15
20
25
PA
PB
PC
PD
PE
Figura 1.8: Esquema de cobertura do template pelos probes para uma leitura de 25 bp.
com frequências menores do que as variantes germinativas. A capacidade de detecção da variante vai
depender da frequência mínima que se deseja detectar e da acurácia das leituras geradas.
1.3.2
Target Sequencing
O ressequenciamento de um genoma inteiro gera um volume enorme de dados e permite fazer uma identificação completa das variações no genoma. Porém, muitas vezes, os pesquisadores só estão interessados
nas variações das regiões codificantes, ou até mesmo num subconjunto de genes e, portanto, sequenciar
todo o genoma para depois selecionar a parte que interessa é bastante ineficiente. Uma alternativa ao
ressequenciamento completo é o target sequencing, na qual a amostra é tratada para selecionar somente
as regiões de interesse.
Existem duas principais abordagens para o target sequencing: captura por hibridização, método utilizado pelos kits SureSelect da Agilent e TargetSeq da Life, e captura por amplificação como o RainStorm
da Rain Dance e o AmpliSeq da Life.
Recomenda-se uma alta cobertra da região de interesse pois, como estamos restringindo o sequenciamento às regiões de interesse, queremos garantir que todas as bases tenham cobertura suficiente para que
possamos fazer a identificação de variações de maneira confiável. Uma recomendação corrente é cobrir a
região de interesse com uma média de cobertura entre 80 e 100 vezes. Mesmo assim, o target sequencing
oferece vantagens de custo e de processamento devido ao volume reduzido de dados, um genoma humano
sequenciado a 20× gera 60Gbps de sequências, enquanto que um exoma sequenciado a 100× gera 5Gbps
de dados.
1.3.3
RNA Seq
RNA Seq, também chamado the Whole Transcriptome Shotgun Sequencing, é o uso de NGS para sequenciar cDNA com a intenção de capturar a informação do transcriptoma de um organimo. Ao contrário de
outras técnicas, como Microarray ou RT-PCR, o RNA Seq não necessita uma lista pre-definida dos gene
que se deseja detectar. A princípio, qualquer transcrito que estiver sendo expresso pode ser detectado se
o experimento tiver cobertura suficiente. Além disso, o RNA Seq permite detectar, além da expressão,
eventos de splicing alternativo e expressão de genes desconhecidos.
Segundo as diretrizes do projeto ENCODE[27], para estudar somente a expressão de transcritos
polyA, uma cobertura de 20 a 25 milhões de reads curtos mapeados é suficiente. Mas para detectar
transcritos raros ou variações e isoformas em uma amostra de mamíferos, é necessário uma cobertura
de 100 a 200 milhões de reads. O projeto ENCODE também recomenda a realização de duas ou mais
replicatas biológicas. Normalmente não é necessário realizar réplicas técnicas.
Um dos problemas em manipular RNA é a sua fragilidade. Por isso é preciso tomar muito cuidado
na manipulação da amostra e também é preciso avaliar a sua qualidade antes de fazer o sequenciamento
(utilizando, por exemplo, o BioAnalyzer da Agilent). Caso a amostra esteja degradada, o resultado é
13
uma taxa muito baixa de reads mapeados. Outro problema é o RNA Ribossomal, ele corresponde a
uma grande quantidade da massa de RNA de uma célula e, se não for removido da amostra no final, a
maioria dos reads será de RNA ribossomal, o que normalmente não é objetivo do experimento. É possível
utilizar um kit de depleção de RNA Ribossomol, como o Ribominus da Invitrogen, ou então fazer um
enriquecimento para RNA com calda polyA, como o poly(A) Purist também da Invitrogen. Caso haja
interesse também em RNAs não codificantes é melhor utilizar somente o Ribominus. Caso contrário, o
poly(A) Purist é mais eficiente (alguns grupos utilizam os dois para garantir a remoção dos ribossomais).
1.3.4
Sequenciamento denovo
Quando não se tem um genoma de referência, é necessário realizar a montagem denovo. O processo de
montagem denovo é muito mais trabalhoso do que o mapeamento com referência. É necessário ter uma
cobertura muito maior e os programas de montagem cometem muito mais erros do que os programas
de mapeamento. Apesar disso, é possível obter bons resultados na montagem de genomas bacterianos
com relativo pouco esforço. Para genomas de organismos superiores, é necessário combinar diversas
tecnologias de sequenciamento e utilizar computadores com quantidades massivas de memória RAM
para efetuar o processo de montagem do genoma.
1.3.5
Metagenoma
A metagenômica é o estudo do material genético extraído diretamente do ambiente. Normalmente,
quando se quer estudar o genoma de uma bactéria, é feita uma cultura para garantir que se está sequenciando um único genoma. Porém, a diversidade de micro-organismos presentes no ambiente é muito maior
do que é possível acessar via sequenciamento individual de bactérias. Por isso, o estudo do metagenoma
é importante.
Existem dois tipos de estudo de metagenomas:
1. Estudo de diversidade utilizando o gene ribossomal 16s: Nesse tipo de estudo amplifica-se por PCR
a sequência 16s e se compara o resultado contra um banco de dados de bactérias conhecidas. Com
isso, é possível avaliar e comparar a diversidade de bactérias presentes na amostra.
2. Shotgun Metagenomics: Nesse segundo caso não se faz nenhuma seleção de alvo. Todo o DNA
extraído da amostra é fragmentado e sequenciado. A análise consiste em montar o “metagenoma”
da amostra para tentar identificar, além da diversidade de genomas, novos genes.
A metagenômica é uma área muito ativa de pesquisa e os métodos de análise ainda são muito manuais.
14
Capítulo 2
Arquivos de Sequência
Em princípio, é bastante simples representar uma sequência de DNA em formato texto. Cada base pode
ser presentada por um caracter: A para Adenina, C para Citosina, G para Guanina e T para timina.
O código oficial para representar DNA é mantido pela IUPAC e inclui também códigos para identificar
bases ambíguas, ou seja, os casos em que não se sabe ao certo a base correta, mas se sabe que deve ser
um C ou T ou algo similar. O código completo está na tabela 2.1.
A
C
G
T (ou U)
R
Y
S
W
K
M
B
D
H
V
N
. ou -
Adenina
Citosina
Guanina
Timina (ou Uracila)
A ou G
C ou T
G ou C
A ou T
G ou T
A ou C
C ou G ou T
A ou G ou T
A ou C ou T
A ou C ou G
qualquer base
gap
Tabela 2.1: Código IUPAC para representar o DNA
Além da informação da base, os sequenciadores também produzem uma estimativa da probablidade
da base detectada estar correta. Usualmente essa probabilidade é representada pelo “Phred Quality
Score”, assim chamado porque foi utilizado pela primeira vez no software phred[5]. A fórmula para
calcular os valores de phred é:
Q = −10 log10 Perro
(2.1)
Onde Perro é a probabilidade da base ter sido identificada de maneira errada1 . Na figura 2.1, temos
o gráfico da função que calcula o phred score e na tabela 2.2 temos exemplos de alguns valors de phred.
Nela vemos que, por exemplo, uma base com phred 20 tem 99% de acurácia, ou seja, uma chance em
100 de estar errada.
1 O score phred é construído com base em uma série de preditores de qualidade que são calibrados com dados reais para
gerar uma estimativa de probabilidade de erro.
15
Q
10
20
30
40
50
Chance de erro
1 em 10
1 em 100
1 em 1000
1 em 10000
1 em 100000
Acurácia da base
90 %
99 %
99,9 %
99,99 %
99,999 %
Tabela 2.2: Valores de qualidade phred, probabilidades de erro e acurácia
Phred Score
40
35
Phred Score
30
25
20
15
10
5
0
0.01
0.02
0.03
0.04
0.05
P de erro
0.06
0.07
0.08
0.09
0.1
Figura 2.1: Gráfico da função que calcula o Phred Score
Tipicamente, os valores de phred score estão entre 1 e 40. Até é possível sequenciar com uma acurácia
maior que 40, porém, a acurácia das etapas anteriores de 99,99%, e a acurácia do processo inteiro não
pode ser maior do que da parte menos acurada, o que é uma consequência da propagação derros.
A maneira mais simples de representar os valores de qualidade em formato texto é uma lista de
inteiros, o que adiciona de 2 a 3 bytes de dados para cada base sequenciada (1 a 2 caracteres para o valor
da qualidade e um caracter como separador entre os valores). Antes do NGS essa forma de representação
era prática porque o volume de dados era pequeno, mas recentemente se tornou necessário criar novos
formatos que economizassem bytes.
Neste capítulo, vamos analisar os formatos de representação de dados de sequenciamento mais usados
e como manipulá-los utilizando ferramentas gratuitas.
2.1
2.1.1
Fasta e FastQ Files
Fasta format
A forma mais universal de representar sequências biológicas é o formato fasta. Este formato foi criado
para o programa de alinhamento de DNA e proteínas FASTA[21]. Por ser um formato texto muito
simples, ele foi sendo adaptado para as mais diversas aplicações. Mas por outro lado muitas aplicações
não seguem o padrão de maneira estrita.
De maneira geral, um arquivo fasta contém uma série de cabeçalhos seguidos pelo texto da sequência.
Cada cabeçalho é definido por uma linha que se inicia com o caracter >. Pelo padrão, linhas que iniciam
com o caracter ; são consideradas comentários, mas algumas aplicações utilizam o caracter # para essa
função. Abaixo vemos um exemplo de arquivo fasta:
16
>HSBGPG Human gene for bone gla protein (BGP) (fragment)
GGCAGATTCCCCCTAGACCCGCCCGCACCATGGTCAGGCATGCCCCTCCTCATCGCTGGGCACAGCCCAGAGGGT
ATAAACAGTGCTGGAGGCTGGCGGGGCAGGCCAGCTGAGTCCTGAGCAGCAGCCCAGCGCAGCCACCGAGACACC
ATGAGAGCCCTCACACTCCTCGCCCTATTGGCCCTGGCCGCACTTTGCATCGCTGGCCAGGCAGGTGAGTGCCCC
CCTGGAGCCCAGGAGGGAGGTGTGTGAGCTCAATCCGGACTGTGACGAGTTGGCTGACCACATCGGCTTTCAGGA
GGCCTATCGGCGCTTCTACGGCCCGGTCTAGGGTGTCGCTCTGCTGGCCTGGCCGGCAACCCCAGTTCTGCTCCT
CTCCAGGCACCCTTCTTTCCTCTTCCCCTTGCCCTTGCCCTGACCTCCCAGCCCTATGGATGTGGGGTCCCCATC
ATCCCAGCTGCTCCCAAATAAACTCCAGAAG
>HSGLTH1 Human theta 1-globin gene (fragment)
CCACTGCACTCACCGCACCCGGCCAATTTTTGTGTTTTTAGTAGAGACTAAATACCATATAGTGAACACCTAAGA
CGGGGGGCCTTGGATCCAGGGCGATTCAGAGGGCCCCGGTCGGAGCTGTCGGAGATTGAGCGCGCGCGGTCCCGG
GATCTCCGACGAGGCCCTGGACCCCCGGGCGGCGAAGCTGCGGCGCGGCGCCCCCTGGAGGCCGCGGGACCCCTG
CTTCTTGCCGTGCTCTCTCGAGGTCAGGACGCGAGAGGAAGGCGC
Neste exemplo, vemos duas sequencias: uma identificada com HSBGPG e outra como HSGLTH1.
Depois de cada identificador temos um espaço e em seguida um comentário sobre a sequência. Depois
disso temos o corpo de cada sequência, o padrão manda que a sequência seja quebrada em linha entre 70
e 132 caracteres. No exemplo, está uma sequência de nucleotídeos, mas o arquivo fasta pode ser utilizado
para representar qualquer tipo de sequência biológica.
O arquivo fasta pode vir acompanhado de um arquivo com extensão .qual. Nesse arquivo estão
os valores de qualidade associados com cada base. Ele tem basicamente o mesmo formato do arquivo
.fasta, porém, no lugar da sequência de bases, ele tem os valores de qualidade na escala phred separados
por espaços. Abaixo temos um exemplo de arquivo .fasta e o respectivo arquivo .qual.
FASTA
>RWBG8:4:5
CTCATTGCCCTCAACACAGTGGAGCGAATTCCTTTGGAAAACCTGCAGATCATCAGAGGAAATATGTACT
ACGAAAATTCCTATGCCTTAGCAGTCTTATCTAACTATGA
QUAL
>RWBG8:4:5
23 16 31 29 30 26 31 31 32 25 32 33 33 29 32 32 31 29 29 29 33 29 31 31 33 31
30 22 29 20 26 18 24 26 12 26 19 25 28 29 13 29 24 32 32 30 30 30 34 33 33 32
33 33 33 33 33 33 29 33 33 25 31 31 29 29 24 24 24 24 24 24 29 29 31 31 18 29
25 29 21 25 25 13 13 15 19 26 22 26 27 28 29 25 31 28 33 29 33 33 33 33 33 29
33 33 34 34 30 30
Como o fasta é um formato de texto, é possível utilizar ferramentas padrão do unix para manipulá-lo.
Para contar o número de sequências em um arquivo fasta, usa-se o seguinte comando:
grep -c "^>" <arquivo.fasta>
Para contar o número de bases no arquivo pode-se utilizar este outro comando:
grep -v "^[>;]" <arquivo.fasta> | wc -c
2.1.2
FastQ format
O formato fasta/qual foi amplamente utilizado para representar sequências geradas por sequenciadores
de Sanger. Porém com o aumento da capacidade dos sequenciadores os arquivos neste formato passaram
a ficar muito pesados. Uma maneira de reduzir o volume de dados foi a criação do formato fastQ. Neste
formato as bases e os valores de qualidade são representados no mesmo arquivo. Além disso as qualidades
são codificadas com caracteres ASCII ao invés de uma sequência de números. Essa codificação é mais
eficiente porque cada valor de qualidade precisa em geral de 3 bytes, dois digitos do valor mais o espaço,
enquanto que no fastQ cada qualidade precisa de somente 1 byte. Abaixo temos um exemplo de arquivo
fastQ:
17
@SEQ_ID
GATTTGGGGTTCAAAGCAGTATCGATCAAATAGTAAATCCATTTGTTCAACTCACAGTTT
+
!’’*((((***+))%%%++)(%%%%).1***-+*’’))**55CCF>>>>>>CCCCCCC65
Nesse formato, o cabeçalho é definido pelo caracter @, e é seguido pelo identificador da sequência. Na
linha seguinte tem-se a sequência e, ao contrário do formato fasta, que manda quebrar a sequência em
diversas linhas, no fastQ deve-se ter somente uma linha (mas muitas vezes essa regra não é respeitada).
Na linha seguinte tem-se o caracter + que pode ser seguido pelo identificador da sequência novamente, e
na última linha tem-se os valores de qualidade representados em ASCII.
Para converter o valor de qualidade phred para fastQ adiciona-se 33 a ele e procura-se o caracter
ASCII correspondente. Este é o padrão definido pelo Sanger Institute e mais utilizado atualmente.
Porém as primeiras versões da pipeline de análise da Illumina definem o valor de qualidade como phred
mais 64, o que pode causar problemas para quem estiver manipulando esses arquivos. A partir da versão
1.8 da pipeline de análises a Illumina também passou a adotar o padrão do Sanger.
Para converter de fastQ para fasta pode-se utiliar o programa seqtk que vem junto com o samtools:
seqtk fq2fa in.fastq > out.fasta
2.2
SFF File
O Standard Flow Format[24], ou SFF, é um arquivo binário que foi desenvolvido em conjunto pela
454 Life Science, o Whitehead Institute e pelo Sanger Institute para representar sequências geradas
por um sequenciador baseado em fluxos como o 454 ou o Ion Torrent. Nesse arquivo a sequência é
representada em termos de fluxos, ou seja, as bases e o tamanho normalizado do sinal detectado. Por
exemplo, a sequência AATGG é representada com o equivalente a A3 T1 G2, mas, como a relação
entre o sinal e o tamanho do homopolímero não é totalmente exata, o comprimento dos homopolímeros
é representado por números fracionados. Assim, o exemplo anterior pode ser algo como: A2.9 T1.1
G1.5. Tal informação é perdida devido aos arredondamentos executados quando se converte de SFF
para fasta, mas um programa que trabalhe diretamente com SFF pode utilizar essa informação para
resolver ambiguidades. Essa informação em termos de intensidade de sinal para cada fluxo também é
chamada de flow space em oposição à sequência pura que está em base space.
O arquivo SFF contém um cabeçalho com informações da corrida, assim como um cabeçalho por
read. Além de informar o nome de cada read e o tamanho, esse cabeçalho contém as informações de
clipping de adaptador e clipping de qualidade. Tendo o arquivo SFF, é possível extrair as sequências
sem o clipping, o que pode ser útil para algumas aplicações.
2.2.1
Converter arquivo SFF para Fasta ou FastQ
Muitos programas não lidam diretamente com arquivos SFF, por isso é necessário fazer a conversão para
formatos mais antigos, como fasta ou fastQ2 . Na tabela 2.3 está a lista de alguns conversores de SFF
gratuitos.
Nome
sff_extract
sff2fastq
Flower
Linguagem
Python
C
Haskell
URL
http://bioinf.comav.upv.es/sff_extract/
https://github.com/indraniel/sff2fastq
http://biohaskell.org/
Tabela 2.3: Conversores de SFF
O conversor mais fácil de utilizar é o sff_extract, pois ele é somente um script em python. Porém,
ele é o conversor mais lento. O sff2fastq é o mais rápido, porém é menos flexível, pois só gera arquivo
no formato fastQ. Por fim, o Flower é rápido e flexível, mas necessita ter a linguagem de programação
Haskell instalada no sistema.
2 O Torrent Browser fornece o resultado da corrida no formato BAM, mas ele também gera as sequências nos formatos
SFF e fastQ por meio de plugins.
18
Converter utilizando o sff_extract
Para utilzar o sff_extract você precisa baixar o script. O nome do arquivo será sff_extract_<versão>.
Renomeie para sff_extract e torne o arquivo executável com o comando chmod +x sff_extract. Para
converter de SFF para fasta/qual utilize o seguinte comando:
sff_extract -o <prefixo> <entrada.sff>
Onde <prefixo> é o nome dos arquivos .fasta e .qual que vão ser gerados e <entrada.sff> é o
nome do arquivo sff que se deseja converter. Este comando vai gerar três arquivos:
• <prefixo>.fasta Com as sequências em formato fasta
• <prefixo>.fasta.qual Com os valores de qualidade em formato phred
• <prefixo>.xml Arquivo XML com as informações extras de cada read, em especial, as informações
de clipping de cada read.
Abaixo temos um exemplo de um registro em um arquivo XML gerado:
<?xml version="1.0"?>
<trace_volume>
<trace>
<trace_name>RWBG8:4:5</trace_name>
<clip_quality_right>149</clip_quality_right>
<clip_vector_left>5</clip_vector_left>
<clip_vector_right>114</clip_vector_right>
</trace>
...
</trace_volume>
Todos os valores de clipping são indexados a partir de 1. Para encontrar a primeira base não trimada,
utiliza-se a seguinte expressão:
f irst_base_position = max(1, clip_quality_lef t, clip_adapter_lef t)
(2.2)
E para achar a última base não clipada utiliza-se (caso os clip_adapter_right ou clip_quality_right
sejam 0, o valor é substituído pelo número total de bases no read):
last_base_position = min(clip_quality_right, clip_adapter_right)
(2.3)
Portanto, o read no exemplo acima possui bases não clipadas entre as posições 5 e 114. Toda essa
informação de clipagem é indicada por soft clipping, ou seja, as bases do adaptador e as de baixa
qualidade são indicadas em minúsculas. Para fezer o hard clipping e gerar um arquivo fasta “limpo”,
utilize o seguinte comando:
sff_extract -c -o <prefixo> <entrada.sff>
Neste caso, serão gerados os mesmos arquivos, porém o arquivo XML não terá as informações de
clipping porque o clipping já foi feito nos arquivos fasta e qual.
Para gerar o arquivo em formato FastQ, utilize:
sff_extract -Q -o <prefixo> <entrada.sff>
ou
sff_extract -c -Q -o <prefixo> <entrada.sff>
Esse comando vai gerar o arquivo <prefixo>.fastq e <prefixo>.xml, e da mesma forma que no
exemplo anterior, se for adicionada a opção -c, o resultado será com hard clipping.
19
Utilizando o seq_crumbs
O sff_extract foi suplantado pelo pacote seq_crumbs. Diferentemente do programa anterior, o seq_crumbs
foi concebido em módulos, que podem ser combinados de maneira muito mais versátil. Além disso, ele
utiliza a biblioteca biopython. Para baixar o programa, utilize esse endereço:
https://github.com/JoseBlanca/seq_crumbs
Já o biopython está disponível em:
http://biopython.org/wiki/Download
Para fazer a conversão de SFF para fastQ utiliza-se:
sff_exrtract -c -o <output> <entrada.sff>
Note que a versão do seq_crumbs só gera arquivos em formato fastq, não tendo mais a opção de
gerar fasta/qual. Como no programa anterior, a opção -c pede para o programa fazer o trimming das
sequências.
Para fazer a conversão de arquivos SFF de mate-pair vemos uma diferença muito maior, pois temos
que combinar o programa sff_extract com o programa split_matepairs:
sff_extract <entrada.sff> |
split_matepairs -l ION_TORRENT
A combinação desses dois comandos é equivalente ao sff_extract -l. Mas o seq_crumbs oferece
mais opções de manipulação de arquivos. É possível também gerar dois arquivos de mates desentrelaçados, ou seja, um arquivo com a primeira tag e outro com a segunda. Para isso utilize:
split_matepairs -l ION_TORRENT |
pair_matcher -p <orphan.fastq> |
deinterleave_pairs -o <out.1.fastq> <out.2.fastq>
O comando pair_matcher remove as tags que estão sem os seus respectivos pares e coloca no
arquivo <orpha.fastq>, já o deinterleave_pairs separa os pares nos arquivos <out.1.fastq> e
<out.2.fastq>.
Utilizando o Flower
O Flower é um utilitário para ler arquivos SFF feito na linguagem de programação Haskell. Por ser
uma linguagem compilada ele é muito mais do que o sff_extract, que foi escrito em Python. Duas
desvantagens é que o runtime do Haskell é menos ubíquo do que do Python e ele não gera o arquivo
XML com as informações de clipagem necessárias para o Mira (ver 6.1).
Tendo instalado o Haskell, é muito fácil instalar o Flower. Basta utilizar o programa Cabal da seguinte
maneira:
cabal install biosff
Para converter um arquivo SFF para fastQ, utiliza-se:
flower -q <entrada.sff> > saida.fastq
Além de converter o SFF, o flower também permite inspecionar o arquivo. Para visualizar o SFF em
formato texto, use:
flower entrada.sff | more
Por fim, o flower gera uma visualização do flow space em um formato tabulado muito útil. Para
gera-la:
flower -F <entrada.sff>
Segue um exemplo de resultado:
20
...
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
RWBG8:9:36
...
81
82
83
84
T
C
G
A
85
86
87
88
T
C
G
A
1.05 Qual {unQual = 34}
0.00
5.72 Qual {unQual = 27},Qual
Qual
Qual
1.93 Qual {unQual = 27},Qual
0.00
0.00
{unQual
{unQual
{unQual
{unQual
=
=
=
=
27},
27},Qual {unQual = 27},
27},Qual {unQual = 7}
21}
Note que mesmo os fluxos que não tiveram sinal são registrados no arquivo SFF e também que,
para os homopolímeros, temos uma estimativa de qualidade para cada uma das bases (quebra de linha
adicionada para facilitar a visualização).
2.3
Unmapped BAM
O formato BAM, discutido na seção sobre mapeamento (seção 3.1.2), é um formato criado para representar o mapeamento dos reads de NGS em um genoma de referência. Ele é um formato binário,
compactado, indexável e amplamento suportado que pode representar tanto reads mapeados como reads
não mapeados. Os campos opcionais do formato BAM permite grande flexibilidade. É possível adicionar
as informações de flow space do Ion e do 454 ou o color space do SOLiD direto no arquivo BAM, fazendo
dele uma alternativa para os formatos nativos.
Para converter de Unmapped BAM para fastQ, pode-se utizar o comando SamToFastq do Picard
(ver seção 3.1.4) da sequinte maneira:
java -jar SamToFastq.jar
2.4
I=<input.bam> FASTQ=<out.fastq>
XSQ Format
O XSQ é o formato nativo do SOLiD 5500. Ele é um formato binário que diminiu em até 60% o número
de bytes necessários para representar o conjunto de sequências no formato fasta/qual. Ele utiliza como
base o HDF5, que é um formato criado para armazenar grandes volumes de dados numéricos.
Esse formato permite representar os reads tanto em base quanto em color space assim como reads
únicos e pareados. Sendo um formato binário, ele também permite o acesso aleatório dos reads contidos
nele. Por fim, é possível adicionar metadados sobre a corrida no próprio arquivo de sequência, facilitando
o armazenamento e a organização dos dados.
As ferramentas de conversão de XSQ para csfasta e vice-versa, assim como a documentação do
formato, estão disponíveis em:
http://www.lifetechnologies.com/us/en/home/technical-resources/software-downloads/xsq-software.
html
Porém, esses conversores só estão disponíveis para Linux CentOS ou RedHat 4 ou 5. Para converter
de XSQ para csfasta utiliza-se:
./convertFromXSQ.sh -f -o <diretorio de sáida>
<in.xsq>
Será criado um diretório Libraries dentro do <diretório de saída>. Dentro de Libraries, será
criado um diretório para cada tag – F3, R3, etc – e dentro deste um diretório reads com os arquivos
csfasta, qual e fastq (caso o sequenciamento tenha sido feito com ECC). A opção -f pede para o programa
filtrar os reads marcados como filtrados pelo basecaller e portanto é altamente recomendável.
Também é possível converter de csfasta/qual para XSQ com o comando convertToXSQ.sh. Dependendo do tipo de biblioteca, é preciso passar diferentes argumentos. Para biblioteca de fragmentos
utiliza-se:
21
./convertToXSQ.sh
-x <out.xsq> --mode Fragment
--c1 <F3.csfasta> --q1 <F3.QV.qual>
--libraryName <libname> --runStartTime "0000-00-00 00:00:00"
E para biblioteca de Long Mate Pair:
./convertToXSQ.sh
-x <out.xsq> --mode LMP
--c1 <F3.csfasta> --q1 <F3.QV.qual>
--c2 <R3.csfasta> --q2 <R3.QV.qual>
--libraryName <libname> --runStartTime "0000-00-00 00:00:00"
--libraryInsertSizeMinimum <inserto min.>
--libraryInsertSizeMaximum <inserto máx.>
Nesse caso temos que informar, além dos campos do arquivo utilizados no caso da biblioteca de
fragmentos, o arquivos do de sequência e qualidade do mate e, o tamanho mínimo do e máximo do
inserto.
22
Capítulo 3
Mapeamento de Sequências
Após um experimento de NGS é quase sempre necessário fazer o mapeamento das leituras geradas em
um genoma de referência. O primeiro programa para fazer esse mapeamento foi o BLAT1 , criado por
Jim Kenth para mapear leituras com alta similaridade contra um genoma de referência. Porém, o BLAT
não consegue alinhar regiões com menos de 40bp e também não tem performance suficiente para alinhar
os milhões de reads gerados por NGS. Os primeiros mapeadores open source otimizados para NGS foram
o MAQ[17] e o SOAP[19], ambos mapeadores que utilizam hash tables para acelerar a busca, com a
diferença que o MAQ indexa os reads enquanto o SOAP indexa o genoma de referência. Com o aumento
do throughput, dos sequenciadores a abordagem de indexar os reads se tornou inviável e por isso os
mapeadores mais recentes indexam a referência.
O problema do uso de hash table é o uso de memória. Alguns mapeadores, como o mapreads
do SOLiD, podem dividir a hash em partes e fazer o mapeamento em etapas de forma a permitir o
mapeamento de grandes genomas mesmo com pouca memória. Alternativamente, é possível utilizar
um FM-Index, que indexa o genoma de referência compactado pela Burrows-Wheeler[33, 6] e entre os
programas que implementam esta técnica estão o BWA[15, 16],bowtie[11] e o SOAPv2[20].
Para aumentar a eficiência os algoritmos citados diminuem a sensibilidade, limitando o número de
mismatches permitidos. Como os reads de NGS normalmente possuem uma qualidade maior no início
do read, utiliza-se uma estratégia de seed and extend: na primeira fase pega-se o início do read, entre 25
e 30 bases, e faz-se a busca permitindo poucos erros – como 2 por exemplo. Encontrada uma posição de
ancoramento do read é feita a extensão do alinhamento de modo a maximizar o score de alinhamento2 .
Na seção seguinte é explorado o format SAM/BAM, que é o formato universal para representar
alinhamentos de NGS e nas próximas seções será mostrado como utilizar alguns mapeadores.
3.1
SAM e BAM Files
O formato SAM, Sequence Alignment/Mapping, é um formato texto criado para representar o resultado
do alinhamento dos reads de NGS contra um genoma de referência[8, 18]. A versão binária no SAM
é chamado de BAM, de Binary SAM, e contém exatamente as mesmas informações, mas em formato
binário. Além do formato binário ser mais eficiente, o arquivo BAM também é compactado em blocos,
o que permite ao mesmo tempo a redução do uso de armazemento e o carregamento parcial do arquivo,
o que é muito importante para programas de visualização.
3.1.1
Estrutura do arquivo SAM
As primeiras linhas do arquivo SAM são o cabeçalho. Estas linhas começam com o caracter @ seguido
por um código de 2 caracteres que identificam o tipo de informação contina na linha. A lista de códigos
está na tabela 3.1. Depois do cabeçalho temos os alinhamentos propriamente ditos, um por linha, com
campos separados por TABs. Na tabela 3.2 está a lista campos de cada alinhamento.
1 O BLAST e o FASTA são programas mais antigos, mas o objetivo deles é fazer buscas em bancos de sequencias e não
especificamente mapear reads em um genoma montado.
2 O BWA-long utiliza uma abordagem um pouco diferente. Em vez de fazer o seed and extend, ele realiza um alinhamento
Smith-Waterman contra o índice BWT do genoma
23
Código
@HD
@SQ
@RG
@PG
@CO
Descrição
Identifica o início do arquivo SAM e a versão dele.
Identifica dada uma das sequências no arquivo de
referência
Read group: identifica conjuntos de reads dentro do
arquivo. Esse registro é muito importante quando
são combinados os resultados múltiplas corridas em
um único arquivo.
Lista de programas utilizados no arquivo.
Comentários
Tabela 3.1: Headers do arquivo SAM
Col.
1
2
3
4
5
6
7
8
9
10
11
12
Nome
QNAME
FLAG
RNAME
POS
MAPQ
CIGAR
RNEXT
PNEXT
TLEN
SEQ
QUAL
FIELDs
Descrição
Nome do read
Bits indicando diversas informações sobre o alinhamento
Nome da sequência na referência
Posição mais à esquerda do read que se alinha na referência
Qualidade do Mapeamento
CIGAR string
Referência do próximo read no par/segmento
Posição do próximo read no par/segmento
Tamanho do template observado
Sequência do read
Qualidade do read codificada utilizando a convenção do fastQ do Sanger
Campos opcionais
Tabela 3.2: Alinhamento no arquivo SAM
Abaixo segue uma descrição mais detalha de cada um dos campos:
1. QNAME: Nome do read ou ’*’ para indicar que a informação não está disponível.
2. FLAG: Bits descrevendo algumas propriedades do alinhamento. o layout dos bits esta abaixo e o
significado de cada bit está na tabela 3.3.
0
M
1
A
2
3
4
5
6
U UM R RM F
7
L
8
9
10
S
Q
D
11
12
13
14
15
Por exemplo, um read corretamente mapeado vai ter um valor de flag 2, mas se ele mapear na
fita oposta a flag vai ser 2 + 16 = 18. Caso o read seja o primeiro de um par a flag vai ser
1 + 2 + 16 + 64 = 83.
3. RNAME: Nome da sequência de referência ou um número indicando qual o registro @SQ do header
com a correspondente sequência. Um read não mapeado tem o valor ’*’ neste campo.
4. POS: Posição mais à esquerda do alinhamento do read com a referência (valores começando em
1). Se o valor for 0, o read não está alinhado.
5. MAPQ: Qualidade do mapeamento. Este valor é representado como um inteiro com interpretação
similar ao índice phred de qualidade, ou seja, P = −10 log10 Q, onde Q é a probabilidade do read
estar mapeado de maneira errada.
6. CIGAR: Sequência de caracteres que descrevem como o read está mapeado na referência. O
significado de cada caracter é o seguinte:
24
Sim.
M
A
U
UM
R
RM
valor
1
2
4
8
16
32
F
L
S
64
128
256
Q
D
512
1024
Descrição
Template com múltiplos segmentos, ou seja, mate-pair ou pairend3 .
Cada segmento está corretamente alinhado.
Segmento não mapeado.
Próximo segmento não mapeado.
O campo SEQ é o reverso complementar do read.
O campo SEQ do próximo segmento é o reverso complementar do
read.
Esse segmento é o primeiro do template.
Esse segmento é o último do template.
Alinhamento secundário. Essa flag indica que existe outro alinhamento desse read que é considerado o primário pelo mapeador.
Esse alinhamento não passou pelo controle de qualidade.
Esse read foi considerado uma duplicata de PCR ou ótica.
Tabela 3.3: Significado e valor de cada flag do format SAM.
M
I
D
N
S
H
P
=
X
Alignment Match (pode ser um match ou um mismatch)
Inserção na referência
Deleção na referência
Intron (este caracter só é utilizado para representar mRNA’s)
Soft clipping (corta uma base presente em SEQ)
Hard clipping (corta uma base não presente em SEQ)
Padding (deleção em uma padded reference)
Sequence Match
Sequence Mismatch
7. RNEXT: Sequência na referência do próximo segmento. Se RNEXT for ’*’ então esta informação
não está presente e se for ’=’ RNEXT tem o mesmo valor e RNAME.
8. PNEXT: Posição do próximo segmento, 0 caso esta informação não esteja disponível.
9. TLEN: Tamanho do inserto entre os segmentos. O segmento à esquerda tem sinal positivo e o
segmento à direita tem sinal negativo, o valor 0 indica que essa informação não está presente.
10. SEQ: Sequência do segmento. Pode ser ’*’ se o valor não tiver sido armazenado. Um ’=’ denota
uma base idêntica à da referência.
11. QUAL: Qualidade das bases de SEQ em formato Sanger FastQ.
Após os campos obrigatórios, pode haver campos opcionais. Esses campos têm o formato
T AG : T Y P E : V ALU E
, onde tag é uma sequência de 2 caracteres que inidcam o campo, TYPE indica o tipo de dado e VALUE
é o valor do campo, para a documentação completa veja a especificação do formato SAM[8].
Na figura 3.1 vemos alguns alinhamentos e as entradas equivalentes em formato SAM. O primeiro
read, r001, tem as seguintes flags 163(= 1 + 2 + 32 + 128) = A + M + RM + L, portanto está corretamente
mapeado (A), é o segundo membro de um par (M +L) e o seu par mapeia na posição 37 na fita oposta (flag
RM ). O read r002 posui três soft-clipped bases, a coordenada mostrada no arquivo SAM é da primeira
base alinhada. A string CIGAR deste alinhamento contém um P (padding) que corretamente alinha a
sequência inserida. A informação de padding pode ser omitida se o alinhador não suportar alinhamento
múltiplo de sequências. As últimas 6 bases do read r003 mapeiam na posição 9, e as 5 primeiras mapeiam
na posição 29 da fita reversa. O hard clipping (H) indica bases que não estão presentes na referência. A
tag opcional NM indica o número de mismatches no alinhamento. O read r004 alinha sobre um intron,
fato indicado pelo caracter N.
25
Figura 3.1: Exemplos de alinhamentos e os respectivos registros em formato SAM[18].
3.1.2
BAM File
O arquivo BAM tem exatamente a mesma estrutura do arquivo SAM, porém as informações estão
codificadas em formato binário para economizar espaço em disco e na memória. Além disso, o formato
BAM possui uma compactação em blocos chamada BGZF, que permite o acesso aleatório ao arquivo
mesmo ele estando compactado. Por ter esssa estrutura de blocos, o arquivo BAM pode ser carregado
parcialmente, o que permite a visualização de arquivos BAM muito grandes, sem exceder a capacidade
da memória RAM. Para fazer esse carregamento, o visualizador utiliza um arquivo auxiliar que indexa
os blocos do arquivo BAM em relação às coordenadas genômicas. Esse arquivo tem o mesmo nome do
arquivo BAM, mas com a extensão .bai, de BAM index. Ele também tem que estar no mesmo diretório
que o arquivo BAM.
3.1.3
Samtools
Junto com o formato SAM/BAM foi criada a ferramenta samtools para manipular esses arquivos. Ele
está disponível no site:http://samtools.sourceforge.net/. Para baixar o código fonte do programa,
vá para a URL:
http://sourceforge.net/projects/samtools/files/samtools/0.1.18/
Após baixar o código fonte compile, com o comando make, será gerado um executável chamado
samtools o qual você pode copiar para o diretório que quiser, como por exemplo /usr/local. A
estrutura geral de execução do samtools está abaixo, command é um dos comandos reconhecidos pelo
samtools e <arg>* são as opções para cada um dos comandos.
samtools <command> <arg>*
A seguir, uma lista de receitas úteis para manipular arquivos SAM/BAM:
• Converter entre SAM e BAM: Para fazer a conversão entre a versão binária e texto utiliza-se
o comando view:
– BAM para SAM: samtools view <input.bam> > <output.sam>
– SAM para BAM: samtools view -S -b <input.sam> > <output.bam>
• Visualizar o header de um arquivo BAM: Para extrair somente o header de um arquivo
BAM, use:
samtols view -H <arquivo.bam>
• Ordenar e indexar um arquivo BAM: Para visualizar e também para realizar diversas análises
é preciso ordenar os alinhamentos de acordo com a posição genômica. Para isso utiliza-se o seguinte
comando:
26
samtools sort <arquivo.bam> <novo.nome>
Onde <novo.nome> é o prefixo do nome do novo arquivo que vai ser gerado com os reads ordenados.
Esse nome não pode ser o mesmo do arquivo original e não precisa colocar a extensão .bam.
Ela é adicionada automaticamente, e se você colocá-la no final vai ter um arquivo com extensão
.bam.bam, o que não é muito elegante. Caso o arquivo bam não caiba na memória disponível
(que é controlada pela opção -m), será gerado um arquivo temporário com o <novo.nome>.X.bam.
No final do processo esses arquivos vão ser combinados e um arquivo chamado <nome.nome>.bam
é gerado. O valor default de -m é 500000000 (500Mb). Se o computador tiver mais memória
disponível e o arquivo BAM for bastante grande, é interessante aumentar esse valor de forma a
agilizar o processo de ordenação do arquivo bam. Portanto, em um computador com 8Gb de RAM
pode-se utilizar algo como:
samtools sort -m 4000000000 <arquivo.bam> <novo.nome>
Por fim, para indexar o arquivo ordenado, utiliza-se
samtools index <novo.nome.bam>
Que vai gerar o arquivo <novo.nome.bai.
Existe um problema no samtools, o comando sort não altera a tag SO, que indica se o arquivo está
ordenado ou não. Desse modo se o arquivo original tiver SO:unsorted, o arquivo gerado ordena
também vai conter SO:unsorted. Alguns programas estão conscientes desse problemas e lidam
com ele, porém caso seja necessário corrigir essa tag é preciso utilizar o comando reheader do
samtools (veja detalhes sobre esse comando mais abaixo).
• Gerar um relatório sobre o mapeamento:
Para conseguir um relatório dos reads mapeados em arquivo BAM, utiliza-se o comando flagstat
da seguinte maneira:
samtools flagstat <input.bam>
Se for aplicado em um BAM file gerado pelo PGM vai gerar um resultado como este:
99525
0 + 0
81284
0 + 0
0 + 0
0 + 0
0 + 0
0 + 0
0 + 0
0 + 0
0 + 0
+ 0 in total (QC-passed reads + QC-failed reads)
duplicates
+ 0 mapped (81.67%:-nan%)
paired in sequencing
read1
read2
properly paired (-nan%:-nan%)
with itself and mate mapped
singletons (-nan%:-nan%)
with mate mapped to a different chr
with mate mapped to a different chr (mapQ>=5)
Os valores são classificados como QC-passed reads e QC-failed reads de acordo com o valor da flag
Q(512) do campo FLAGS. Todos os valores estão divididos nessas duas categorias. Esse exemplo
não tem nenhum read marcado com QC-failed e portanto os valores no segundo grupo são todos
zero. A maioria dos valores nesse relatório diz respeito a bibliotecas de reads pareados, e como
essa era uma biblioteca de fragmentos, então o valor mais importante é o número e à porcentagem
de reads mapeados, no caso 81.284, 81,67% do total de 99.525 reads. Abaixo vemos o resultado do
flagstat em um arquivo de reads mate-pair do SOLiD:
27
844482954 + 0 in total (QC-passed reads + QC-failed reads)
225681606 + 0 duplicates
688865129 + 0 mapped (81.57%:nan%)
844482954 + 0 paired in sequencing
422241477 + 0 read1
422241477 + 0 read2
345539940 + 0 properly paired (40.92%:nan%)
533247304 + 0 with itself and mate mapped
155617825 + 0 singletons (18.43%:nan%)
178287164 + 0 with mate mapped to a different chr
90834280 + 0 with mate mapped to a different chr (mapQ>=5)
• Combinar diversos arquivos BAM em um novo arquivo: Para combinar diversos arquivos
bam em um novo arquivo utiliza-se:
samtools merge <out.bam> <input1.bam> <input2.bam> ...
Porém, essa opção vai simplesmente copiar o header do arquivo <input1.bam> e combinar os
alinhamentos de todos os arquivos, mas isso pode fazer com que as tags @SQ, @RG e @PG fiquem
inconsistentes entre o header e os alinhamentos. Por isso, é necessário criar um novo header, com
as informações corretas, e utilizar o comando:
samtools merge -rh <novo.header.txt> <out.bam>
<input1.bam> <input2.bam> ...
Onde <novo.header.txt> é o header gerado pelo usuário. Alternativamente, o usuário pode
utilizar o comando MergeSamFiles do pacote Picard (seção 3.1.4), que atualiza o header ao fazer
o merge.
• Substituir o header de um arquivo BAM: Para substituir o header de um arquivo BAM, crie
um novo header em um arquivo texto e utilize o seguinte comando:
samtools reheader <novo.header.txt> <arquivo.bam> > <novo.arquivo.bam>
Por exemplo, se quiser modificar a tag SO de unsorted para coordinate, utilize os seguintes
comandos:
samtools view -H <arquivo.bam> |
sed ’s/SO:unsorted/SO:coordinate/’ > header.txt
samtools rehader header.txt <arquivo.bam> > <fixed.bam>
3.1.4
Picard
Picard é um conjunto de programas para manipular arquivos SAM/BAM escritos em Java e é um
excelente complemento ao samtools. A página do projeto é http://picard.sourceforge.net/ e um
arquivo .tar.gz, com os pacotes jar já compilados pode ser baixado em:
http://sourceforge.net/projects/picard/files/picard-tools/1.67/
O pacote está estruturado como uma série de arquivos jar, sendo que cada jar é um comando. A
estrutura geral para executar um comando é a seguinte:
java -jar <path de instalação>/<comando>.jar <args*>
Cada ferramenta tem um conjunto próprio de argumentos, porém, alguns argumentos que são comuns
à todas as ferramentas podem ser visualizados na tabela 3.4. Abaixo temos alguns comandos úteis do
Picard, neles o path de instalação está omitido para deixar mais limpa a linha de comando.
28
Argumento
MAX_RECORD_IN_RAM
TMP_DIR
CREATE_INDEX
Descrição
Número máximo de registros à serem mantidos na
memória. Aumentando esse valor reduze-se o número de operações intermediárias de disco. Default:
500.000
Diretório temporário
Cria arquivo de índice .bai.
Tabela 3.4: Argumentos comuns a todos os comandos do Picard.
1. Ordenar um arquivo BAM: O Picard possui um comando similar ao samtools sort, que é o
SortSam.jar:
java -jar SortSam.jar
I=<entrada.bam> O=<sorted.bam>
SO=coordinate
CREATE_INDEX=true
A grande vantagem do SortSam.jar em relação ao samtools sort é que esse comando atualiza
de maneira apropriada o header do arquivo, trocando a tag SO para coordinate. Para ordenar
arquivos muito grandes é interessante aumentar o valor de MAX_RECORD_IN_RAM. Em uma máquina
com uma boa quantidade de RAM pode-se aumentar esse valor em 10×, como por exemplo:
java -jar SortSam.jar
I=<entrada.bam> O=<sorted.bam>
SO=coordinate
CREATE_INDEX=true
MAX_RECORD_IN_RAM=5000000
2. Fazer o merge de diversos arquivos BAM: O Picard também possui uma alternativa ao
comando samtools merge
java -jar MergeSamFiles.jar
O=<resultado.bam> I=<input1.bam> I=<input2.bam>...
MSD=true
AS=true USE_THREADING=true CREATE_INDEX=true
Assim com o SortSam.jar, o MergeSamFiles.jar trata melhor o header do arquivo gerado do que o
comando equivalente do samtools. Por default ele gera corretamente as tags @RG e @PG no header,
e com a opção MERGE_SEQUENCE_DICTIONARIES, ele também gera as tags @SQ corretas. A opção
AS significa “Assume Sorted” e existe para lidar com o fato do samtools não atualizar o header do
arquivo gerado, e portanto indicar como unsorted um arquivo ordenado. A opção USE_THREADING
faz com que o programa utilize duas threads 4 .
Quando se deseja combinar diversos arquivos BAM juntos, é um pouco tedioso colocar uma argumento I=<file.bam> para cada arquivo. É possível combinar o MergeSamFiles com o comando
find do unix para combinar todos os arquivos BAM em um mesmo diretório.
java -jar /share/apps/picard/MergeSamFiles.jar
O=<out.bam>
USE_THREADING=true MSD=true
‘find -name \*.bam -printf "I=%p\n"‘
4 Linhas de execução do programa. Em um sistema com mais de um processador/core essa opção aumenta a performance
do programa, podendo reduzir o tempo de processamento em 20%
29
3. Identificar Read Duplicados:
Durante o preparo de biblioteca pode ocorrer a duplicação de um fragmento, o que causa um viés
artificial da região que originou o fragmento. Por isso, é recomendado que reads suspeitos de serem
duplicatas sejam marcados e ignorados nas análises subsequentes. O MarkDuplicates.jar procura
reads nos quais as posições mais 5’ do alinhamento e a orientação sejam iguais. O read com a
melhor qualidade não é alterado e todos os outros são marcados como duplicados. Para bibliotecas
de mate-pair e pair-end ocorre o mesmo, porém as cordenadas e a orientação dos dois pares de reads
devem coincidir[9]. Uma vantagem do MarkDuplicates.jar é que ele consegue encontrar duplicatas
mesmo se os reads do par não mapearem no mesmo cromossomo.
Para executar o comando utilize:
java -jar MarkDuplicates.jar I=<input.bam>
O=<input.dups.bam>
M=<input.dups_report.txt> AS=true
CREATE_INDEX=true
3.2
Mapeando os reads com o TMAP
O Ion Torrent possui um mapeador otimizado para o padrão de erros dos dados gerados pelo sequenciador. Chamado de TMAP, ele foi criado por Nils Homer. O TMAP é otimizado para os reads de
tamanho variável e também para lidar com erros de homopolímeros gerados pelo Ion Torrent. Para isso,
ele implementa quatro algoritmos de mapeamento que podem ser utilizados individualmente ou combinados. A lista de algoritmos está na tabela 3.5. Na figura 3.2 temos uma comparação da sensitividade
(porcentagem de reads mepados) dos algoritmos do TMAP para o dataset de E. Coli O104H45 . Por
comparação foi também colocada a performance bowtie2 e vemos que este tem uma performance um
pouco superior ao map1, porém inferior a todos os outros algoritmos (pelo menos para esse dataset).
Vê-se que o desempenho de map3 e map4 foi bem superior aos outros dois algoritmos, o que gera o
questionamento do porquê deles terem sido incluídos. Na figura 3.3, temos os tempos de processamento
dos mesmos dados da figura anterior. Podemos notar que o map1, apesar de menos eficiente em relação
à porcentagem de reads mapeados, é mais rápido do que map3 e map4.
Para equilibrar sensitividade e performance, temos o comando mapall. Ele aplica cada algoritmo de
mapeamento em estágios definidos pelo usuário. Dessa forma somente os reads que não mapearem em
um estágio são passados para o estágio seguinte. Portanto, uma abordagem eficiênte é colocar o map1
no primeiro estágio, para fazer rapidamente o mapeamento dos reads “fáceis”, e em seguida usar o map3
e o map4 para mapear o resto dos reads.
O código fonte do TMAP está disponível no site github:
https://github.com/iontorrent/TMAP
Para ter uma melhor performance o TMAP pode opcionalmente utilizar o TCMalloc da gperftools
que está disponível em:
http://code.google.com/p/gperftools/
map1
map2
map3
map4
Algoritmo
BWA Short
BWA Long
SSAHA
SMEM
Referência
Li and Durbin [15]
Li and Durbin [16]
Ning [25]
Li [14]
Tabela 3.5: Algoritmos do TMAP
3.2.1
Criando o índice
O primeiro passo para usar o TMAP é gerar o índice do genoma de referência. Para isso, utiliza-se o
comando index da seguinte forma:
5 Disponível
na Ion Community
30
80
75
map %
70
65
60
bowtie2
map1
map2
map3
map4
Figura 3.2: Sensitividade dos algortmos do tmap e do bowtie2 (Amostra de E. Coli O104H4)
tmap index -f <referecen.fasta>
Caso haja bases ambíguas na referência, será mostrada uma mensagem de aviso e as bases ambíguas
serão trocadas, dentre as bases possíves, pela de menor valor lexicográfico. Por exemplo, a base Y, que
representa C ou T, será trocada por C, a base N que representa qualquer base será trocada por A, e
assim por diante. A indexação do genoma humano pode demorar 4 horas em um computador atual. O
resultado será diversos arquivos com os índices.
3.2.2
Mapeando os reads
O comando para aplicar um dos algoritmos é:
tmap <mapN> -f <reference> -r <reads>
Onde mapN é map1, map2, map3 ou map4, <reference> é nome de um arquivo fasta que já tenha
sido indexado e <reads> é o arquivo dos reads, que pode estar em formato, fasta, fastQ ou SFF. Como
resultado o tmap gera um arquivo SAM na saída padrão. Caso se utilize um arquivo SFF, é possível
propagar a informação dos flows para o aquivo SAM por meio da opção -Y. Também é possível utilizar
diversas threads com a opção -n <num threads>.
A opção -o X controla o formato de saída do programa, -o 0 é o default e gera uma saída texto em
formato SAM, -o 1 gera um resultado binário em formato BAM, e por fim -o 2 gera um arquivo BAM
não comprimido, uma opção útil se o resultado for tmap vai ser enviado para um outro comando para
mais processamentos, como por exemplo no comando abaixo, que combina o tmap com o samtools sort:
tmap <mapN> -f <reference> -r <reads> -o 2 |
samtools sort -n <memoria> - <output>
Normalmente, os algoritmos individuais não são utilizados, mas sim o comando mapall. Com esse comando você pode combinar os algoritmos em estágios adicionando argumentos no formato stageM mapX*
que define quais algoritmos serão utilizados em cada estágio. É possível definir diversos estágios de modo
que, se um read não mapear em um determinado estágio, ele é passado para o estágio seguinte. Uma
estratégia é colocar o map1 no primeiro estágio, porque ele é mais rápido, e o map3 e o map4 no segundo
estágio. Para isso, utilizamos o seguinte comando:
31
150
100
map time (s)
50
map1
map2
map3
map4
Figura 3.3: Performance dos algoritmos do tmap (Amostra de E. Coli O104H4)
tmap mapall -f <reference> -r <reads>
stage1 map1 stage2 map3 map4
Também é possível controlar as informações da tag @RG através da opção -R. Isso é importante porque
outros programas validam essa tag ao abrir o arquivo BAM. E além disso é bom adicionar metadata
sobre a amostra para facilitar a organização dos arquivos. Algumas tags que podem ser utilizadas são:
ID
Identificador único do read group
SM cancer
Nome da amostra (sample)
LB hg19
Nome da biblioteca
CN USP
Nome do centro de sequenciamento
PU PGM/318
A utilização varia entre plataformas. No PGM tem sido usado
para identificar o tipo de chip
utilizado.
PL IONTORRENT Nome da plataforma de sequenciamento (esses valores são tabelados pelo formato SAM)
Combinando todas as informações apresentadas, uma sugestão para rodar o TMAP é a seguinte:
tmap mapall -n <num threads> Y -f <reference> -r <reads.sff>
-R LB:<LB> -R CN:<CN> -R PU:PGM/<chip>
-R ID:<ID> -R SM:<SM> -R PL:IONTORRENT
stage1 map1 stage2 map2 map3 -o 2|
samtools sort - <output>
3.2.3
Exemplo: Mapeando os reads de E. coli com o TMAP
1. Faça o download do arquivo SFF com os reads no site da Ion Community: http://lifetech-it.
hosted.jivesoftware.com/docs/DOC-1518
2. Descompacte o arquivo zip com os reads.
32
3. Faça o download da referência no site do NCBI:http://www.ncbi.nlm.nih.gov/nuccore/NC_
010473.1 em formato fasta e renomeie o arquivo dh10b.fasta
4. Indexe a referência: tmap index -f dh10b.fasta
5. Utilize o TMAP para mapear os reads na referência. Para mapear uma amostra utilize:
tmap mapall -Y -f dh10b.fasta -r 64.sff
-R LB:O104H4 -R CN:uni-munster -R PU:PGM/314
-R ID:64 -R SM:ecoli -R PL:IONTORRENT
stage1 map1 stage2 map2 map3 -o 2 |
samtools sort - 64
Para mapear todas as amostras você pode utilizar o comando for do bash:
for file in *.sff; do
base=‘basename $file .sff‘ ;
tmap mapall -Y -f dh10b.fasta -r $file
-R LB:O104H4 -R CN:uni-munster -R PU:PGM/314
-R ID:$base -R SM:ecoli -R PL:IONTORRENT
stage1 map1 stage2 map2 map3 -o 2|
samtools sort - $base ;
done
6. Marque os reads duplicados: utilize o comando MarkDuplicates.jar do picard para identificar os
reads duplicados:
java -jar MarkDuplicates.jar
I=64.bam O=64.dups.bam M=64.dups.txt AS=true
Ou utilize o for para processar todos os arquivos bam:
for file in *.bam; do
base=‘basename $file .bam‘ ;
java -jar MarkDuplicates.jar
I=$file O=$base.dups.bam M=$base.dups.txt AS=true
done
7. Faça o merge dos arquivos bam utilizando o MergeSamFiles.jar do Picard:
java -jar MergeSamFiles.jar O=O104H4.bam
‘ls *.dups.bam | sed s/^/I=/‘
USE_THREADING=TRUE SO=coordinate MSD=true
8. Verifique os parâmtros do resultado utilizando o comando flagstat do samtools:
samtools flagstat O104H4.bam
3.2.4
Mapeando dados de Long Mate Pair
O TMAP também suporta o mapeamento de reads pareados. A principal diferença quando se utiliza o
mapeamento pareado ao invés do normal é que no primeiro caso o mapeador vai fazer o pareamento dos
reads, ou seja, ela vai indicar para cada read a posição do seu respectivo par (colunas RNEXT e PNEXT
do arquivo BAM).
Para fazer o mapeamento é preciso primeiro separar as tags do mate-pair utilizando o seq_crumbs
(veja seção 2.2.1). O comando para fazer a extração é:
33
split_matepairs -l ION_TORRENT |
pair_matcher -p <orphan.fastq> |
deinterleave_pairs -o <out.1.fastq> <out.2.fastq>
Para fazer o mapeamento utilze o seguinte comando:
tmap mapall -Q 1 -f <ref.fasta> -r <out.1.fastq> -r <out.2.fastq> -o 2
stage1 map1 stage2 map3 map4 > <out.bam>
É importante colocar a opção -Q 1 para indicar que os dados são de mate-pair e colocar a opção -r
duas vezes, uma para cada arquivo dos pares.
3.3
Bowtie
O bowtie[11] é um mapeador bastante popular criado para mapear short reads. Ele é especialmente
eficiente para reads com 50bp ou menos. O bowtie suporta dados tanto em base quanto color space.
A versão mais nova, bowtie 2[12], suporta alinhamentos com gaps e por isso é mais adequado para
reads com 100bp ou mais. Infelizmente ele não suporta mais color-space. Em termos de algoritmo, o
bowtie 2 é muito similar ao TMAP, dividindo o mapeamento em uma primeira etapa de alinhamento
sem gaps seguida de uma etapa de alinhamento Smith-Waterman. Diversos softwares utilizam o bowtie
como mapeador, em especial o pipeline de análise de RNA-Seq Tophat[32] e o pipeline na nuvem de
ressequenciamento Crossbow[13].
3.3.1
Utilizando o Bowtie 2
O bowtie2 está disponível na seguinte URL:
http://bowtie-bio.sourceforge.net/bowtie2/index.shtml
É possível baixar tanto os binários para Mac ou Linux quanto o código fonte do programa. Após
descompactar o pacote, adicione o diretório do bowtie2 ao path ou faça um link dos binários contidos
nele para um /usr/local/bin ou outro diretório que já esteja no path.
O uso do bowtie2 é muito similar ao tmap, até porque ambos se baseiam nos mesmos princípios.
Inicialmente, é necessário indexar a referência utilizando o comando bowtie2-index da seguinte forma:
bowtie2-build -f <ref.fasta> <prefix>
Onde <prefix> é o prefixo do nome dos arquivos de índice que vão ser gerados. Esse nome vai ser
depois utilizado para referenciar os índices. Para mapear um arquivo fastq utiliza-se:
bowtie2 -p <threads> <prefix> <reads.fastq>
Onde <threads> é o número de threads a utilizar, <prefix> é o prefixo usado na criação do índice
e <reads.fastq> é o arquivo com os reads à mapear. Diferentemente do TMAP, o bowtie2 só suporta
reads em formato fasta ou fastq, não em SFF. Para gerar diretamente os alinhamentos em formato BAM,
combina-se o bowtie com o samtools:
bowtie2 -p <threads> <prefix> <reads.fastq>
| samtools view -Sbh | samtools sort -m <memory> - <output>
Onde <memory> é a quantidade de memória utilizada na ordenação dos reads e <output> é o nome
do arquivo de saída sem a extenção .bam.
34
3.3.2
Utilizando o Bowtie 2 com o Ion Torrent
Vamos agora mapear os mesmos dados utilizados com o TMAP (seção 3.2) com o Bowtie 2. Assim
como no caso do TMAP, a primeira etapa é indexar o genoma de referência. Para isso, utilize o seguinte
comando:
bowtie2-build dh10b.fasta dh10b
Como o bowtie não suporta o formato sff, é preciso fazer a conversão para fastQ. Para isso, utilize
um do programas descritos na seção 2.2, como por exemplo o sff_extract:
sff_exract -c 64.sff
Ou então empregue o comando for para converter todos os arquivos:
for i in *.sff; do
sff_extract -c $i
done
Em seguida, vamos usar o bowtie para fazer o mapeamento:
for i in data/*.fastq; do
b=‘basename $i .fastq‘
bowtie2 -p 8 -q dh10b $i
| samtools view -Suh | samtools sort - $b.bowtie2
done
3.4
Visualizando arquivos BAM com o IGV
A ferramenta mais popular para visualizar arquivos BAM é o IGV do Broad Institute. O IGV é um
programa em java disponível para Linux, Mac OS e Windows. É possível baixar o programa como um
stand-alone, assim como via Java Web Start. Ele está disponível no seguinte link:
http://www.broadinstitute.org/software/igv/download
É possível iniciar o IGV utilizando a tecnologia de WebStart, que cuida automaticamente do download
do aplicativo e o inicia no computador do usuário. Na página serão mostrados quatro ícones para iniciar
o IGV, o que muda entre eles é a configuração de memória. Escolha a opção de acordo com a quantidade
de memória disponível no seu computador, o tipo de sistema operacional e se você está rodando no modo
de 32 ou 64 bits. Alternativamente você pode ir até a seção “Binary Distribution” para baixar o arquivo
zip com o programa. Após baixa-lo, basta executar o programa igv.bat no Windows e o igv.sh no
Linux ou Mac OS.
Vamos demonstrar o IGV utilizando um dataset do Comprehensive Cancer Panel, disponível em:
http://ioncommunity.lifetechnologies.com/docs/DOC-3012
Baixe o arquivo FLO-528.bam.gz, em seguida descompacte-o e crie o índice .bai:
gunzip FLO-528.bam
samtools index FLO-528.bam
No IGV, vá para o menu File, escolha Load from File... e selecione o arquivo FLO-528.bam.
Inicialmente o IGV não vai mostrar nenhuma informação porque o nível de zoom está muito alto. Para
visualizar os alinhamentos é necessário selecionar uma das regiões capturadas pelo ampliseq. Para isso,
vá na caixa de texto na toolbox superior e coloque o nome do gene MTRR. Como o IGV tem a anotação
do genoma humano, ele vai focalizar a janela principal na região onde se encontra o gene MTRR, no caso
entre as coordenadas 7,865,776 e 7,901,794 do cromossomo 5 como pode ser visto na caixa de texto, que
mudou de MTRR para as coordenadas da região mostrada.
Na figura 3.5 vemos o um screenshot do IGV mostrando a região selecionada. A parte principal da
tela está dividida em duas regiões: No topo, temos a barra de navegação que mostra o cariótipo do
cromossomo que está sendo exibida e a região que está sendo mostrada, que é indicada por uma pequena
35
barra vermelha no cariótipo. Logo abaixo temos uma escala com as coordenadas da região. No resto
da tela são mostrados os arquivos carregados. No caso, temos o arquivo bam com os alinhamentos e na
parte de baixo temos a anotação do genoma. É possível adicionar outras seções na visualização, basta
abrir novos arquivos e a tela será subdividida verticalmente para acomodar as novas visualizações.
A visualização do arquivo bam está dividade em duas regiões. No topo temos um gráfico que mostra
a cobertura, ou seja, o número de reads cobrindo cada base do genoma. Na parte de baixo temos o alinhamento de cada read. No nível e zoom do gene inteiro podemos ver poucos detalhes dos alinhamentos,
mas pelo gráfico de cobertura já é possível verificar a eficiência do processo de captura. Vemos que as
leituras estão nas regiões do exons, o que é exatamente o objetivo do processo de captura.
Figura 3.4: IGV mostrando os alinhamentos do reads na região do gene MTRR
É possível mudar o nível de zoom através dos botões “-” e “+” no canto superior direito da tela.
Também é possível aumentar o nível de zoom com um click duplo em um ponto de interesse. Com o click
duplo será feito o zoom e a tela será centralizada no ponto de click. Por fim, é possível mudar o zoom e
a posição digitando novas coordenadas na caixa de texto. Pode-se aumentar o zoom até ser possível os
núcleotídeos do genoma.
Na figura 3.5 vemos o zoom de um dos exons do gene MTRR. Nesse nível de zoom podemos ver cada
um dos reads alinhados na região, representados pelas caixas cinzas. A seta na ponta do read indica o
sentido do alinhamento. Todas as posições em cinza indicam que a base no read é igual à da referência,
qualquer troca é indicada como um retângulo colorido, já inserções são indicadas como um I azul e
deleções são indicadas como uma quebra com um traço preto no read.
Podemos obter mais informações sobre cada read e cada posição basta deixar o ponteiro do mouse
parado em uma posição e uma popup box irá aparecer (fig 3.6. Também é possível colocar o mouse sobre
a cobertura e o IGV irá informar a quantidade de reads na posição indicada, assim como a quantidade
de cada base, deleções e inserções.
Clicando na região com o nome do arquivo é possível mudar a visualização do painel com os alinhamentos. Mudar a visualização de “Expanded” para “Collapsed” permite ter uma visão mais geral dos
alinhamentos, com menos foco em cada alinhamento individual. Na figura 3.7 vemos que o exon em
questão está coberto por reads vindos de dois amplicons diferentes com um pequeno overlap no meio.
Vemos também mais claramente duas trocas nucleotídicas. É possível também mudar a visualização
dos genes, só que o padrão é tê-los em “Collapsed”, o que é díficil de visualizar se o gene tiver diversas
isoformas diferentes ou se houver genes com overlap em fitas opostas. Nesses casos recomenda-se mudar
a visualização dos genes para “Expanded”.
36
Figura 3.5: IGV mostrando os alinhamentos dos reads na região do gene MTRR
3.4.1
Importanto o genoma de referência
Na seção anterior trabalhamos com dados de humano mapeados contra a versão hg19 do genoma, que
é um dos genomas distribuídos pelo Broad Institute para utilizar com o IGV. Porém, frequentemente
temos que trabalhar com outro genomas não disponibilizados ou até mesmo com genomas novos, criados
pelo próprio grupo de pesquisa. Nesses casos é preciso importar o genoma antes de poder visualizar
qualquer alinhamento. Para fazer essa operação escolha o item “Import Genome...” no meu File. Será
aberta uma caixa de diálogos com os seguintes items:
• Unique Identier Um ID para o genoma, deve ser único para todos os genomas registrados no
programa, por exemplo “human_hg19”.
• Descriptive Name Um nome descritivo, que vai aparecer na lista de genomas do menu pull down.
• FASTA File Arquivo fasta com o genoma.
• opcional Cytoband file Arquivo com as informações. Ele permite gerar a ilustração das citobandas
na área superior do IGV.
• opcional Gene file Arquivo com a anotação do genoma em formato BED ou GFF.
• opcional Alias file Um arquivo com duas colunas que determina uma relação entre os nomes das
sequências (cromossomos, contigs etc.) do genoma e da anotação, por exemplo, podemos ter um
genoma cuja sequência se chame chr9, mas no arquivo de genes está somente 96 .
Após preencher todos os campos o IGV irá perguntar onde salvar o arquvo .genome que será criado
com todas as informação necessárias para a visualização. Esse é um arquivo binário que deve ser mantido
para futuros usos do genoma criado. A criação do genoma só precisa ser feita uma vez. Após criado, ele
passa a fazer parte do menu de genomas disponíveis da instalação local do IGV.
6 Uma exceção para essa regra são os nomes no formato NCBI, se por exemplo a sequência do genoma tiver a forma
gi|125745044|ref|NC_002229.3|, mas na anotação estiver a forma curta NC_002229.3, o IGV fará a associão entre as duas
automaticamente.
37
Figura 3.6: Popup boxes do IGV. A) Popup que aparece quando se deixa o cursor sobre um dos reads.
B) popup mostrado quando se deixa o cursor sobre o gráfico de cobertura.
Figura 3.7: IGV com os alinhamentos no modo colapsado. Destaque para duas posições com trocas de
nucleotídeos.
38
Capítulo 4
Arquivos de Anotação de Genomas
A sequência linear de bases que formam o genoma é somente o primeiro nível de informação genética.
Codificados nela estão os genes e os elementos de regulação de expressão gênica. Para identificar a
posição desses elementos, utiliam-se arquivos de anotação, que em geral nada mais são do que arquivos
texto que associam coordenadas genômicas com características ou features. A seguir vamos descrever
alguns formatos de arquivos de anotação.
4.1
BED Formats
O formato BED foi criado pela UCSC para descrever anotações em um genoma. Ele é um formato muito
associado ao UCSC Browser e possui diversos campos que descrevem a representação gráfica da anotação
pelo visualizador. Ele é um formato texto, com colunas separadas por caracteres TAB que representa
intervalos no genoma associados à anotação ou feature[7].
Existem três variações do formato BED, a versão padrão, a versão bedDetail e a versão bedGraph,
além de uma versão binária chamada de bigBed.
Em comum, todos os formatos têm as seguintes colunas:
1. chrom: Nome do cromossomo ou scaffold.
2. chromStart: Posição incial da anotação (iniciando em 0)
3. chromEnd: Posição final da anotação.
Além das linhas descrevendo as features, um arquivo bed pode ter um cabeçalho que começa com a
palavra track e descreve outros atributos utilizados na representação gráfica das regiões.
No formato bedDetail se adicionam mais duas colunas, tendo assim a seguinte estrutura:
1. chrom: Nome do cromossomo ou scaffold.
2. chromStart: Posição incial da anotação (iniciando em 0)
3. chromEnd: Posição final da anotação.
4. Nome: Nome da região
5. Description: Descrição da região
O formato bedDetail é utilizado pelo Ampliseq Designer para informar as regiões cobertas pelo painel.
Na figura 4.1, vemos um exemplo de bedDetail file gerado pelo programa.
39
track
chr1
chr1
chr1
...
chr1
chr1
chr1
...
name="4477685_CCP_Designed" description="Amplicon_Insert_4477685_CCP" type=bedDetail
2488068 2488201 AMPL242431688 . TNFRSF14
2489144 2489273 AMPL262048751 . TNFRSF14
2489772 2489907 AMPL241330530 . TNFRSF14
...
...
...
...
6528161 6528293 AMPL294026880 . PLEKHG5
6528282 6528404 AMPL294029495 . PLEKHG5
6528391 6528519 AMPL294044396 . PLEKHG5
...
...
...
...
Figura 4.1: Exemplo de arquivo bedDetail
4.2
Formatos GFF e GTF
O GFF é outro formato texto utilizado para representar anotações. O formato passou por diversas
revisões, sendo a mais recente o GFF3. Originalmente, GFF significava Gene Finding Format, mas foi
rebatizado para Generic Feature Format para representar o aumento de escopo do formato. Além do
GFF3, também é comumente utilizado o formato GTF (também chamado de GFF2.5). O formato GFF
é mantido pelo projeto Sequency Ontology[31].
A estrutura do GFF é bastante similar ao do formato BED mas com alguns campos que refletem a
sua origen ligada a programas de gene finfing:
1. SeqId: Identificação do cromossomo ou sequência da qual a anotação faz parte.
2. Source: Programa ou algorítmo que gerou a anotação.
3. type: Descreve a natureza biológica da anotação, como “gene” ou “exon”. Tem que ser um termo
do SOFA1 ou um código do Sequence Ontology[4].
4. start: Posição inicial da anotação em relação à sequência identificada na primeira coluna. O
sistema de coordenadas começa em 1.
5. end: Final da anotação, tem de ser um valor igual ou maior que start.
6. score: Nas versões iniciais, esse campo não estava bem definido. Atualmente se recomenda que
se utilize o p-value para predição de genes ou o e-value para mapeamento.
7. strand: Fita da anotação, + para a fita positiva e − para a fita negativa.
8. phase: Para anotações como CDS, essa coluna indica o início da anotação em relação ao frame
de leitura. O valor de 0 indica que o próximo códon começa na primeira base, 1 que é preciso pular
uma base e assim por diante até 2.
9. attributes: Lista de pares tag=valor. Os pares são separados por ;. A lista de tags que podem
ser utilizadas é aberta, mas algumas têm semântica predefinida.
A lista das tags predefinidas para a coluna atributos está na página do formato, vale resaltar algumas:
• ID: Identificador da anotação, tem que ser único no arquivo.
• Parent: ID da anotação pai.
Com as tags ID e Parente é possível definir qualquer estrutura hierárquica no genoma, como por
exemplo a relação gene–transcrito–exon. Abaixo temos um exemplo de anotações em GFF:
1 Sequence
Ontology Feature Annotatio
40
ctg123 example mRNA 1300 9950 . + . ID=t_012143;gene_name=EDEN
ctg123 example exon 1300 1500 . + . Parent=t_012143
ctg123 example CDS 3301 3902 . + 0 Parent=t_012143
ctg123 example CDS 5000 5500 . + 1 Parent=t_012143
ctg123 example CDS 7000 7600 . + 1
Parent=t_012143
Uma outra abordagem para representação de genes e transcritos é o formato GTF. Este formato é
quase idêntico ao GFF3, só mudando a coluna attributes. Em vez de utilzar o formato tag=valor, ele
utiliza tag "valor", e em vez de usar uma estrutura genérica de pai e filho entre as anotações, ele exige
os seguintes atributos:
• gene_id: ID do gene associado à esta anotação
• transcript_id: ID do transcrito
Utilizando um mesmo valor de gene_id e variando o trascript_id é possível representar as informações de splicing alternativo. Essa é uma solução bem menos flexível do que a do GFF3. Abaixo um
exemplo de anotação em formato GTF:
381
381
381
381
381
Twinscan
Twinscan
Twinscan
Twinscan
Twinscan
CDS
CDS
CDS
start_codon
stop_codon
380
501
700
380
708
401
650
707
382
710
.
.
.
.
.
+
+
+
+
+
0
2
2
0
0
gene_id
gene_id
gene_id
gene_id
gene_id
"001";
"001";
"001";
"001";
"001";
transcript_id
transcript_id
transcript_id
transcript_id
transcript_id
"001.1";
"001.1";
"001.1";
"001.1";
"001.1";
É possível converter de GTF para GFF utilizando o comando gffread que faz parte do cufflinks2 :
gffread <in.gtf> -o <out.gff>
E também de GFF pra GTF:
gffread -T <in.gff> -o <out.gtf>
4.3
Gerando arquivos de anotação
Pode-se obter os arquivos de anotações de genomas bem estudados, pode-se usar os serviços dos bancos
de dados de anotações, como o UCSC ou o Ensembl. Caso o genoma de interesse não esteja nessas bases
de dados, é possível encontrar informações de anotações, normalmente feitas automaticamente por um
programa, na página do projeto de montagem do genoma.
4.3.1
Obtendo anotações do UCSC Browser
O UCSC Browser possui um serviço chamado Table Browser[10] que permite exportar as informações de
sua base de dados para diversos formatos, entre eles o bed e o GTF. Essa ferramenta está disponível em:
http://genome.ucsc.edu/cgi-bin/hgTables
Na figura 4.2 vemos tela de seleção de informações do site. Na primeira linha de combo boxes
escolhe-se o genoma de interesse e a versão deste, por default será mostrado o genoma humano na versão
hg19. Abaixo pode-se escolhe o grupo e a “track” de anotações, no caso vamos deixar no grupo “Genes
and Gene Prediction” e na track “UCSC Genes”. Por fim, podemos escolher qual tabela que queremos
exportar. No caso vamos escolher a tabela “knownGene”. Existem diversas opções de filtragem e é
até possível fazer operações de bancos de dados com as anotações, mas o que nos interessa é o seletor
2 http://cufflinks.cbcb.umd.edu/
41
Figura 4.2: UCSC Table Browser site
“Output Format” (ver figura 4.2) que permite escolher, entre outros formatos, GTF e BED. Logo abaixo
é possível esolher um nome para o arquivo que vai ser gerado e também escolher para que o arquivo seja
enviado já comprimido com o programa gzip, reduzindo assim o tamanho do download. Por fim, clica-se
em “Get Output” para fazer o download das anotações.
Figura 4.3: Escolha de regiões ao exportar arquivo BED
Caso se escolha gerar um arquivo em formato BED, será mostrada uma outra tela que permite escolher
as regiões do gene que serão incluídas no arquivo gerado (ver figura 4.3). São oferecidas as seguintes
opções:
• Whole Gene
• Upstream by X bases
• Exons plus X bases at each end
42
• Introns plus X bases at each end
• 5’ UTR Exons
• Coding Exons
• 3’ UTR Exons
• Downstream by X
Na figure 4.4 podemos ver graficamente os diferentes tipos de arquivos BED gerados.
4.4
Manipulando arquivos BED
Uma ferramenta muito útil para manipular arquivos de anotação é o bedtools. Apesar do nome, a
ferramente suporta tanto formato BED quanto GFF, GTF, VCF, SAM e BAM. O código está disponível
em:
https://code.google.com/p/bedtools/
4.4.1
Extrair sequências da regiões
Para extrair a sequência das regiões indicadas pelo arquivo bed utiliza o comando getfasta do bedtools:
bedtools getfasta -fi <genome.fasta> -bed <file.bed> -fo <regions.fasta>
43
44
Figura 4.4: Diferença entre os tipos de arquivos BED gerados pelo UCSC Table Browser.
Capítulo 5
Detecção de Variâncias
Em um projeto de sequenciamento, o passo natural seguinte ao mapeamento é a detecção de diferenças
entre o genoma sequenciado e o genoma de referência. Com uma biblioteca de fragmentos é possível
detectar Single Nucleotide Polymorphism, normalmente chamados de SNPs (se pronuncia “esnipe”), e
pequenas inserções/deleções (usualmente chamados de indels).
Com uma biblioteca de mate-pair, também é possível detectar variações estruturais como grandes
indels e inversões. Neste capítulo vamos abordar somente a detecção de SNPs e de small-indels.
5.1
VCF Files
O formato VCF (Variant Call Format), assim como o formato BAM, foi criado pelo 1000 Genomes
Project para representar as variações detectadas[26]. O arquivo VCF é um arquivo texto. No topo do
arquivo, há um cabeçalho, indicado pelas linhas que começam com #. Depois do cabeçalho, uma lista
de VCF Records, um por linha. Cada campo do registro é colocado em uma coluna, a lista das colunas
está abaixo:
1. CHROM: Cromossomo ou contig da variante.
2. POS: Posição da variante iniciando a contagem por 1.
3. REF: Bases da referência.
4. ALT: Bases alternativas. Se houver mais de uma alternativa, elas serão listadas separadas por
vírgulas.
5. QUAL: Score da variante em escala phred.
6. FILTER: Se a variante passou pelos controles de qualidade: PASS; caso contrário uma lista de
códigos separos por vírgulas descrevendo por que ela foi rejeitada.
7. INFO: Lista de valores separados por dois pontos com estatísticas sobre as variantes. Os valores
estão na forma <chave>=<valor>, onde chave é uma string curta que identifica o valor. Abaixo,
temos uma lista de chaves definidas pelo padrão. Todas elas são opcionais e os usuários podem
também adicionar chaves extras. No entanto as chaves abaixo são reservadas:
• AA: Alelo Ancestral
• AC: Contagem por alelos
• AF: Frequência de cada alelo
• AN: Número total de alelos
• BQ: RMS1 da qualidade para essa posição
1 Root
• CIGAR: Cigar String descrevendo como um alelo alternativo se alinha no alelo de referência
pP
2
Mean Square:
i
xi
45
• DB: Membro do dbSNP
• DP: Cobertura para todas as amostras
• END: Posição final da variante descrita nesse registro
• H2: Membro do hapmap2
• H3: Membro do hapmap3
• MQ: RMS do mapping quality
• MQ0: Número de reads com M Q = 0
• NS: Número de samples
• SB: Strand Bias nessa posição
• SOMATIC: Indica que essa variante é somática
• VALIDATED: Validado por outro experimento
• 1000G: Membro do 1000 Genomes
Um exemplo com as 8 primeiras colunas de um arquivo VCF está na tabela 5.1. Depois da 8a coluna
podemos encontrar informações de genótipo. Primeiro temos uma coluna chamada FORMAT, a qual
define uma lista com tipos de dados (separados por dois pontos). Em seguida temos uma coluna para
cada amostra com os valores definidos por FORMAT, e no cabeçalho está o nome de cada amostra.
Vemos um exemplo na tabela 5.2. Neste, caso temos a informação de genótipos para duas amostras,
NA000001 e NA000002.
#CHROM
20
20
20
20
POS
14370
17330
1230237
1234567
ID
rs6054257
.
.
microsat1
REF
G
T
T
GTC
ALT
A
A
.
G,GTCT
QUAL
29
3
47
50
FILTER
PASS
q10
PASS
PASS
INFO
NS=3;DP=14;AF=0.5
NS=3;DP=11;AF=0.017
NS=3;DP=13;AA=T
NS=3;DP=9;AA=G
Tabela 5.1: Exemplo de lista de variantes em arquivo VCF (parte obrigatória).
FORMAT
GT:GQ:DP:HQ
GT:GQ:DP:HQ
GT:GQ:DP:HQ
GT:GQ:DP
NA00001
0|0:48:1:51,51
0|0:49:3:58,50
0|0:54:7:56,60
0/1:35:4
NA00002
1|0:48:8:51,51
0|1:3:5:65,3
0|0:48:4:51,51
0/2:17:2
Tabela 5.2: Exemplo de lista de variantes em arquivo VCF (definição de genótipos).
Assim como para o campo INFO, existem diversas chaves predefinidas para o genótipo. Abaixo temos
a lista definida pelo padrão:
• GT: Genótipo, codificado como valores de alelo separados por / ou |. O alelo da referência é
indicado por 0, o primeiro alelo em ALT é indicado por 1, o segundo por 2, e assim por diante.
Para um genoma diplóide esse campo pode ser 0/1, 1|0, 1/2 e assim por diante. Para um genoma
monoplóide, somente um valor deve ser dado, e para um genoma triplóide podemos ter algo como
0|0|1. A diferença dos separadores é que / indica genótipos fora de fase e | indica genópicos em
fase.
• FT: A mesma coisa que o campo FILTER, porém individual para a amostra.
• GL: log10 da verossimillhança para possível genótipo. Se A for o alelo de referência e B o alelo
alternativo, a ordem dos genótipos é AA,AB e BB (a fórmula geral para a ordem dos genótipos
está explicada no apêndice 7.1).
• GLE: Verossimilhança do genótipo usado quando existe incerteza de copy mumber.
46
• PL: Valores de GL em scala phred.
• GP: Probabilidade à posteriori dos genótipos em escala phred.
• CQ: Probabilidade condicional do genótipo estar errado, dado que o locus é variante (em escala
phred):
−10 log10 p(genótipo está errado|locus é variante)
(5.1)
• HQ: qualidade dos halótipos, dois valores separados por vírgula em escala phred.
• PS: Phase Set, definido como o conjunto de genótipos em fase que este genótipo pertence.
• PQ: Qualidade da atribuição de fase do genótipo, em escala phred.
• EC: Lista separada por vírgulas do valor esperado da contagem de cada alelo alternativo listado
na coluna ALT.
• MQ: RMS do mapping quality, similar à encontrada na coluna INFO.
Além dos registros VCF, o arquivo contém um header. Esse header é bastante útil porque adiciona
uma descrição texto para vários campos contidos no arquivo. Para os campos padrão pode-se consultar
a especificação do padrão, mas para campos específicos de algum programa a descrição no arquivo
é bastante útil. Em especial as linhas INFO e FORMAT descrevem as chaves das colunas INFO e
FORMAT no arquivo. Abaixo temos um exemplo de VCF header:
##fileformat=VCFv4.1
##fileDate=20090805
##source=myImputationProgramV3.1
##reference=file:///seq/references/1000GenomesPilot-NCBI36.fasta
##contig=<ID=20,length=62435964,assembly=B36,
md5=f126cdf8a6e0c7f379d618ff66beb2da,species="Homo sapiens",taxonomy=x>
##phasing=partial
##INFO=<ID=NS,Number=1,Type=Integer,Description="Number of Samples With Data">
##INFO=<ID=DP,Number=1,Type=Integer,Description="Total Depth">
##INFO=<ID=AF,Number=A,Type=Float,Description="Allele Frequency">
##INFO=<ID=AA,Number=1,Type=String,Description="Ancestral Allele">
##INFO=<ID=DB,Number=0,Type=Flag,Description="dbSNP membership, build 129">
##INFO=<ID=H2,Number=0,Type=Flag,Description="HapMap2 membership">
##FILTER=<ID=q10,Description="Quality below 10">
##FILTER=<ID=s50,Description="Less than 50% of samples have data">
##FORMAT=<ID=GT,Number=1,Type=String,Description="Genotype">
##FORMAT=<ID=GQ,Number=1,Type=Integer,Description="Genotype Quality">
##FORMAT=<ID=DP,Number=1,Type=Integer,Description="Read Depth">
##FORMAT=<ID=HQ,Number=2,Type=Integer,Description="Haplotype Quality">
5.1.1
Manipulando arquivos VCF
Como o arquivo VCF é uma tabela com colunas separadas por tabulação, pode facilmente ser lido (no
caso de um arquivo de tamanho razoável) em um planilha eletrônica como o Excel ou Open Office Calc.
Também pode ser facilmente manipulado utilizando scripts e utilitários do unix.
5.1.2
Indexando as variantes
Para visualizar o arquivo vcf no IGV é necessário comprimi-lo e indexá-lo primeiro. Para isso utilizamse duas ferramenta criadas pelo grupo do samtools: o bgzip e o tabix, ambos disponíveis no seguinte
endereço:
http://sourceforge.net/projects/samtools/files/tabix
O bgzip é um compactador de blocos2 e o que ele faz é aplicar o algoritmo de compressão em blocos
do arquivo de entrada. Já o tabix cria um índice que permite que o visualizador carregue na memória
somente as variantes associadas à região que está sendo mostrada na tela. Para utilizá-los no arquivo
VCF:
2 Esse
é o mesmo formato de compactação utilizado pelo arquivo BAM
47
bgzip <var.vcf>
tabix -p vcf var.vcf.bgz
5.2
Utilizando o samtools para detectar SNPs
O samtools é uma ferramenta geral para a manipulação de arquivos BAM e já foi abordada na seção
3.1.3. Ele também permite fazer análises simples de SNPs através do comando mpileup. Nessa seção
vamos mostar como usar o samtools gerar um arquivo em formato BCF3 e depois fazer a chamda de
SNPs. Para mais detalhes sobre o formato pileup, veja o apêndice 7.2. Para gerar o arquivo BCF,
usa-se4 :
samtools mpileup -d <max cov> -f <ref.fasta>
-g <align.bam> > <out.bcf>
Esse resultado não é uma lista de SNPs, mas sim um BCF intermediário que será utilizado para fazer
a chamada. É possível visualizar esse arquivo com o seguinte comando:
bcftool view <out.bcf> | less
A descrição dos campos do arquivo intermediário está no apêndice 7.3. Finalmente para aplicar o
modelo estatístico e fazer a chamada de SNPs utilizamos o bcftools da seguinte maneira:
bcftools view -D<cobertura> -c -v -b <out.bcf> > <var.raw.bcf>
A opção -c pede para o bcftools fazer a chamada de SNPs, a opção -v pede para o programa gerar
somente os sítios com variantes e a opção -b pede para gerar o resutado em formato BCF. Se você utilizar
a opção -g em vez de -c também é gerada a informação de genótipos.
O algoritmo do bcftools não é muito restritivo, por isso é recomendável filtrar a lista de SNPs. Junto
com o samtools vem o script vcfutils.pl que tem uma opção varFilter para fazer isso:
bcftools view -c -v <var.raw.bcf> | vcfutils.pl varFilter > <vars.vcf>
É possível mudar valores dos parâmetros de filtragem através dessas opções:
Default
Opção Descrição
-Q
minimum RMS mapping quality for SNPs
10
-d
minimum read depth
2
-D
maximum read depth
10000000
-a
minimum number of alternate bases
2
-w
SNP within INT bp around a gap to be filtered 3
-W
window size for filtering adjacent gaps
10
-1
min P-value for strand bias (given PV4)
0.0001
-2
min P-value for baseQ bias
1e-100
-3
min P-value for mapQ bias
0
-4
min P-value for end distance bias
0.0001
-e
min P-value for HWE (plus F<0)
0.0001
5.2.1
Gerando um arquivo consenso
Muitas vezes deseja-se um arquivo fasta com o consenso das regiões cobertas, para isso é possível utilizar
o vcfutils.pl da sequinte maneira:
samtools mpileup -uf <ref.fa> <aln.bam> |
bcftools view -cg - |
vcfutils.pl vcf2fq > consensus.fastq
O resultado é um arquivo fastQ, para convertê-lo para fasta utiliza-se o comando seqtk5 :
seqtk fq2fa consensus.fastq > consensus.fasta
3 Binary
VCF
gerar um arquivo BCF não comprimido, troca-se o -g por -u.
5 ver seção 2.1.2
4 Para
48
5.3
Utilizando o GATK
O GATK, Genome Analysis Toolkit é um software desenvolvido pelo Broad Institute para análise de
dados de nova geração, com ênfase na análise de variantes e genotipagem. Ele está disponível em:
http://www.broadinstitute.org/gatk/download
O programa tem uma estrutura modular, sendo dividio em diversas análises, todas empacotadas junto
com o framework em um arquivo jar. Para ter a lista de análises utiliza-se o comando:
java -jar GenomeAnalysisTK.jar
Para executar uma análise específica:
java -jar GenomeAnalysisTK.jar -T <analysis> <args*>
Na proxima seção vamos mostrar a utilização do GATK para fazer uma chamada de variantes em
dataset de ampliseq.
5.3.1
Chamando Variantes no GATK
Para demonstar a chamada de variantes com o GATK vamos utilizar um dataset do comprehensive
cancer panel. As estapas da análise são as seguintes:
1. Fazer o download dos arquivos FLO-528.bam.gz e CCP.bed.gz em:
Tendo os arquivos, é necessário decompactá-los e indexar o arquivo bam com os seguintes comandos:
gunzip FLO-528.bam.gz
gunzip CCP.bed.gz
samtools index FLO-528.bam
2. Recriar o genoma de referência utilizado no mapeamento. A sequências dos cromossomos está
disponível no UCSC:
http://hgdownload.cse.ucsc.edu/goldenPath/hg19/bigZips/chromFa.tar.gz
Porém, a sequência mitocondrial utilizada está no Genbank:
http://www.ncbi.nlm.nih.gov/nuccore/NC_012920
É preciso baixá-la em formato fasta e salvar com o nome de chrM.fa. Depois, é preciso editar esse
arquivo, mudando o header para:
>chrM
Em seguida, é preciso descompactar os cromossos e concatená-los junto com o genoma mitocondrial
em um único arquivo:
tar zxvf chromFa.tar.gz
cat chr[1-9].fa chr[12][0-9].fa chrX.fa chrY.fa chrM.fa
> hg19.fasta
Por fim, é preciso indexar o arquivo fasta utilizando o samtools:
samtools faidx hg19.fasta
E criar o dicionário de sequências do arquivo com o o Picard:
java -jar CreateSequenceDictionary.jar
R=hg19.fasta O=hg19.dict
49
3. Fazer a chamada de variantes:
java -jar
-I
-L
-o
GenomeAnalysisTK.jar -T UnifiedGenotyper
FLO-528.bam -R hg19.fasta
CCP.bed
SNP1.vcf
O resultado é o arquivo SNP1.vcf, com a lista de SNP encontrados.
5.3.2
Anotando as variantes com o dbSNP
Uma das primeiras análises a ser feite com uma lista de variantes é comparar elas com a base de SNPs
comnhecidas do NCBI, o dnSNP. Para isso, é necessário baixar o arquivo vcf com o dbSNP:
ftp://ftp.ncbi.nih.gov/snp/organisms/human_9606/VCF/00-All.vcf.gz
A princípio, seria muito fácil utilizar esse arquivo para anotar o arquivo de variantes gerado pelo
variant caller. O problema é a diferença nos nomes dos cromossomos, o dbSNP utiliza 1, 2, 3 etc nos
nomes dos cromossomos e a referência que utilizamos para fazer a chamada utiliza o padrão da UCSC:
chr1, chr2 etc. Para resolver essas discrepâncias podemos utilizar um script que mude os nomes dos
cromossomos no dbSNP. O script está disponível no apêndice 7.4. Para fazer a conversão:
gzcat 00-All.vcf.gz | addchr.pl
> dbsnp-chr.vcf
O passo seguinte é indexar o arquivo vcf gerado. A melhor alternativa para isso é utilizar o igvtools:
igvtools index dbsnp-chr.vcf
Por fim faz-se a anotação:
gatk -T VariantAnnotator -R hg19.fasta -D dbsnp-chr.vcf
-V FLO-528.vcf -o FLO-528.ann.vcf
O resultado vai ser um novo arquivo vcf chamado FLO-528.ann.vcf, com o rsID dos SNPs conhecidos
no campo ID.
5.4
Utilizando Ion Varriant Caller
É possível baixar o plugin Torrent Suite Variant Caller (TSVC) na Ion Community e utilizá-lo para
fazer a chamada de variantes em um outro computador. A versão 2.2 do plugin está disponível em:
Deve-se baixar o Offiline Installer, que nada mais é do que um arquivo zip chamado:
variantCaller-2.2.3.31037.zip
Descompacte esse arquivo no mesmo diretório dos dados6 :
unzip -x variantCaller-2.2.3.31037.zip
Vai ser criado um diretório chamado variantCaller com o programa. O comando para fazer a
chamada de variantes é o seguinte:
mkdir FLO-528-tsvc ;
./variantCaller/variantCaller.py
-r ./variantCaller/
-p ./variantCaller/paramFiles/ampliseq.Somatic.json
-b CCP.bed
FLO-528-tsvc
hg19.fasta
FLO-528.sorted.bam
6 É possível instalar em qualquer diretório que se queira, basta depois mudar a linha de comando para refletir essa
mudança.
50
É necessário criar o diretório onde os resultados vão ser escritos, o programa não faz isso sozinho,
por isso a primeira linha. É preciso também passar o diretório onde o TSVC está instalado com a
opção -r. Em seguida, informa-se qual o arquivo com os parâmetros para a chamada de variantes,
no caso escolhemos o arquivo ampliseq.Somatic.json, o nome do arquivo é a combinação do tipo de
biblioteca com o nível de estringência desejado, no caso uma biblioteca de ampliseq com a estringência
para variantes somáticas, ou de baixa frequência. Os arquivos de parâmetros disponíveis estão na tabela
5.3. O parâmetro -p informa o arquivo .bed com as regiões que foram capturadas. Por fim, temos os
seguintes argumentos: diretório de saída, genoma de referência e arquivo .bam. Os arquivos com os
resultados vão ser:
• FLO-528-tsvc/SNP_variants.vcf: Somente os SNPs chamados.
• FLO-528-tsvc/indel_variants.vcf: Somente os indels chamados.
• FLO-528-tsvc/TSVC_variants.vcf: Ambos os arquivos combinados.
Tipo de biblioteca
Estringência
ampliseq
ampliseq
targetseq
targetseq
fullgenome
fullgenome
Germ Line
Somatic
Germ Line
Somatic
Germ Line
Somatic
Tabela 5.3: Lista de parâmetros para Torrent Suite Variant Caller (TSVC)
5.5
Anotando os SNP’s com o snpEff
O snpEff é uma ferramenta muito útil para comparar um arquivo VCF com as anotações de um genoma.
Ele está disponível em:
http://snpeff.sourceforge.net/
Após baixá-lo o primeiro passo é baixar o arquivo binário com as anotações do genoma desejado. O
arquivo snpEff.config contém a lista dos genomas disponíveis. Para baixar as anotações do hg19:
java -jar snpEff.jar -c snpEff.config
download hg19
Os arquivos vão ser gravados no diretório ~/snpEff/data/hg19. A localização desses dados pode ser
mudada editando o arquivo de configuração snpEff.config. Para anotar um arquivo VCF utiliza-se:
java -jar snpEff.jar eff
-c snpEff.config
hg19 SNP_variants.vcf >
SNP_variants.snpeff.vcf
O resultado vai ser um novo arquivo VCF com uma tag EFF no campo INFO, descrevendo o efeito
do SNP. Essa tag contém uma lista de registros com a seguinte estrutura:
Effect ( Effefct_Impact | Codon_Change | Amino_Acid_change |
Gene_Name | Gene_BioType | Coding | Transcript |
Rank [ | ERRORS | WARNINGS ] )
Abaixo vemos um exemplo de um registro:
NON_SYNONYMOUS_CODING(MODERATE|MISSENSE|Aag/Gag|K1222E|2240|PDE4DIP||CODING|NM_001198832.1|29|1)
51
Ele mostra um mutação não sinônimo no transcrito MN_001198832.1 do gene K122E. A descrição de
cada um dos campos é:
1. Effect: Efeito da variantes. A lista dos efeitos que o programa detecta está na tabela 5.4.
2. Effect impact: Impacto do efeito. Pode ter os seguintes valores: High, Moderate, Low, Modifier.
3. Functional class: Classe funcional: NONE, SILENT, MISSENSE, NONSENSE.
4. Codon_Change: Mudança de códon, no formato: codon original/novo codon.
5. Amino_Acid_change: Mudança de aminoácido, no formato: AA antigo posição novo AA (ex:
’E30K’)
6. Amino_Acid_length: Tamanho da proteína em aminoácidos (tamanho do transcrito dividido por
3).
7. Gene_name: Nome do gene.
8. Gene_bioType: bioType do gene, se disponível. Segue as convenções do ENSEMBL. Por exemplo:
protein_coding.
9. Gene_Coding: Pode ser CODING ou NON_CODING. Caso o gene esteja marcado como codante de
proteína ou não.
10. Trancript: ID do transcrito (usualmente ENSEMBL IDs)
11. Exon/Intron Rank: Posição do Exon ou do Intron (ex: ’1’ para o primeiro exon, 2 para o segundo
etc)
12. Genotype: Número do genótipo desse efeito (ex: ’2’ se o efeito corresponde ao segundo ALT)
13. Warnings / Errors: Qualquer aviso ou erro (não é mostrado se estiver vazio).
Efeito
INTERGENIC
UPSTREAM
UTR_5_PRIME
UTR_5_DELETED
START_GAINED
SPLICE_SITE_ACCEPTOR
SPLICE_SITE_DONOR
START_LOST
SYNONYMOUS_START
CDS
GENE
TRANSCRIPT
EXON
EXON_DELETED
NON_SYNONYMOUS_CODING
SYNONYMOUS_CODING
FRAME_SHIFT
Descrição
A variante está na região intergênica
Região Upstream do gene (por default até 5k bases)
Variante na região 5’UTR
A variante deleta um exon que está na região 5’UTR.
A variante na região 5’UTR produz um sequência de 3 bases que
pode ser um START códon.
A variante está em um splice acceptor site (definido como as duas
bases antes do início do exon, exceto para o primeiro exon).
A variante está em um Splice donor site (definido como as duas
bases depois do exon, exceto para o último exon).
Variante converte um start codon em um non-start codon. Ex:
aTg/aGg, M/R)
Variante converte um start codon em outro start codon. Ex:
Ttg/Ctg, L/L (TTG and CTG can be START codons)
A variante está em um CDS.
A variante está em um gene.
A variante está em um transcrito.
A variante está em um exon.
Uma deleção que remove um exon.
A variante faz o códon gerar um amino ácido diferente. Ex:
Tgg/Cgg, W/R
A variante mudao o códon, mas não o amino ácido. Ex: Ttg/Ctg,
L/L
Uma inserção ou deleção que gera um frame shift, por exemplo
um indel que não seja múltiplo de 3.
52
Um ou mais códons são modificados. Por exemplo, um MNP7 de
tamanho múltiplo de 3.
CODON_INSERTION
Um ou mais códons inseridos, por exemplo uma inserção múltipla
de 3 na fronteira de um códon.
CODON_CHANGE_PLUS_CODON_INSERTION Um códon foi modificado e um ou mais foram inseridos. Ex: uma
inserção múltipla de 3, mas não na fronteira do códon.
CODON_DELETION
Um ou vários códons foram deletados. Ex: Uma deleção múltipla
de três na fronteira do códon.
CODON_CHANGE_PLUS_CODON_DELETION
Um códon foi modificado e um ou mais foram deletados. Ex: Uma
deleção múltipla de três, mas não na fronteira do códon.
STOP_GAINED
Variante gera um STOP codon. Ex: Cag/Tag, Q/*
SYNONYMOUS_STOP
Variante modifica um STOP codon em outro STOP codon. Ex:
taA/taG, */*
STOP_LOST
Variante muta um STOP codon em um não STOP codon. Ex:
Tga/Cga, */R
INTRON
A variante atinge um intron. Tecnicamente, ele não atinge um
exon no transcrito.
UTR_3_PRIME
A variante atinge a região 3’UTR.
UTR_3_DELETED
A variante apaga um exon que está na região 3’UTR do transcrito.
DOWNSTREAM
Downstream do gene (por default até 5K bases).
INTRON_CONSERVED
A variante está em uma região intrônica altamente conservada.
INTERGENIC_CONSERVED
A variante está em uma região intergênica altamente conservada.
INTRAGENIC
A variante atinge um gene, mas nenhum transcrito nesse gene.
RARE_AMINO_ACID
A variante atinge um aminoácido raro, portanto tem grandes
chances de produzir uma perda de função.
NON_SYNONYMOUS_START
Variante muta um start codon em outro start start codon (o novo
códon produz um AA diferente). Ex: Atg/Ctg, M/L (ATG e CTG
podem ser START codons)
Tabela 5.4: Lista de efeitos preditos pelo snpEff
CODON_CHANGE
7 Multiple
nucleotide polimorphism
53
54
Capítulo 6
Montagem denovo
Nos capítulos anteriores foram discutidas técnicas de análise que envolvem o mapeamento das sequências
obtidas em um genoma de referência, porém, quando não se tem o genoma de referência do organismo
estudado é preciso gerar, ou montar, esse genoma de novo, ou seja, pela primeira vez. Ao contrário do
mapeamento em que os algoritmos estão muito bem estabelecidos, a área de montagem de genomas é
muito mais experimental e ainda um campo muito ativo de pesquisa[3, 30].
Neste capítulo vamos mostrar como usar o montador Mira[2] para montar genomas bacterianos com
dados do Ion Torrent PGM.
6.1
Montando o genoma com o Mira
O Mira está disponível no sourceforge. Atualmente existem duas versões disponíveis, a 3.4 estável e a 3.9
em desenvolvimento. Normalmente, é melhor utilizar sempre a versão estável, porém um dos focos da
versão em desenvolvimento é o suporte ao ion torrent, motivo pelo qual vamos abordar as duas versões.
Ambas as versões estão disponíveis em seus respectivos diretórios em:
http://sourceforge.net/projects/mira-assembler/files/MIRA/
É possível baixar o código fonte e também versões precompiladas para Linux. Também é necessário
baixar o programa sff_extract (ver 2.2.1). Para fazer a montagem, vamos utilizar o dataset disponível
em:
Nessa página, estão disponíveis os arquivos SFF de três corridas do PGM, uma de fragmentos e duas
de mate-pair. Também está disponível o genoma de referência, para podermos comparar a montagem,
e o arquivo com a sequência dos linkers, que precisamos para extrair os dados de mate-pair. Para a
demonstração, baixe os seguintes arquivos:
C11-127_40X.sff.zip
Corrida de fragmentos (subsampled)
FRA-257_40X.sff.zip
Corrida de mate pair de 3.5kbp (subsampled)
C28-140_40X.sff.zip
Corrida de mate pair de 8.9kbp (subsampled)
MG1655.fasta.gz
Genoma de referência
LMP_Linkers.fasta.gz Sequência dos linkers
No caso, sugere-se utilizar as versões que foram subsampled para que a cobertura fosse somente 40
vezes o tamanho do genoma. Nota-se que utilizar uma coberutra muito alta geralmente piora a qualidade
de montagem, pois os erros se acumulam e geram muitos pequenos contigs.
A primera etapa é transformar o arquivo sff em fastq, mas para isso é preciso utilizar o programa
sff_extract. Deve-se utilizar esse programa e não os outros citados na seção 2.2.1 porque ele gera
também um arquivo XML com as informações de clipagem das sequências. Um ponto muito importante
é seguir a convenção de nomes do Mira, o arquivo de sequências tem que ter o seguinte nome:
<proj>_in.<platform>.fastq
Já o arquivo XML tem que ter este nome:
<proj>_traceinfo_in.<platform>.xml
55
No caso do Ion Torrent <platform> tem que ser iontor e <proj> é o nome escolhido para o projeto.
O comando para fazer a conversão tem a seguinte estrutura:
sff_extract -s <proj>_in.iontor.fastq
-x <proj>_traceinfo_in.iontor.xml
<arquivo.sff*>
A fórmula geral para executar o mira é a seguinte:
mira
--project=frag
--job=denovo,genome,accurate,iontor
Na opção --project utilizamos o mesmo nome dos arquivos, e com isso o Mira vai utilizar os arquivos
corretos. Na opção --job descrevemos o job de montageme as opções são: denovo ou mapping, genome
ou est, accurate ou draft e a lista de tecnologias à serem utilizadas.
Além dessas, é possível adicionar uma série de outras opções que fazem o ajuste do algoritmo e do
comportamento do programa, alguns exemplos são:
-GE:not=x
Ajusta o número de threads do programa para x. O Mira utiliza 2 threads
por default. Aumentar esse valor agiliza o processo, mas somente em uma das
etapas, o algoritmo SKIM.
-OUT:ora=1 Pede para o Mira gerar um arquivo .ace como saída da montagem. Esse arquivo
pode depois ser utilizado para visualizar a posição dos reads nos contigs.
Os resultados vão estar em um diretório chamado <project>_assembly, e dentro deste vão estar os
seguintes diretórios:
• <project>_d_info Diretório com informações sobre a montagem. Normalmente, o primeiro arquivo à se verificar após o término do programa é o <project>_info_assembly.txt, que contém
as estatísticas mais relevantes sobre a montagem.
• <project>_d_results Diretório com os arquivos da montagem, contém os seguintes arquivos:
– <project>_out.unpadded.fasta (e .qual) Arquivo com os contigs montados e respectivo
arquivo de qualidade.
– <project>_out.padded.fasta (e .qual) Versão do arquivo anterior com ’*’ adicionados em
posições nas quais exista uma pequena evidência de bases adicionais.
– <project>_out.maf Montagem no formato nativo do Mira.
– <project>_out.caf Montagem no formato CAF, criado pelo Sanger1 .
– <project>_out.ace Arquivo .ace compatível com diversos visualizadores de montagem. Gerado pela opção -OUT:ora=1. Também pode ser gerado com o comando convert_project
do próprio mira.
• <project>_d_chkpt Checkpoint do montador, pode ser apagado após o término da montagem.
• <project>_d_tmp Diretório com arquivos temporários, também pode ser apagado.
Na proximas seções vamos detalhar como utilizar o Mira em diferentes situações.
6.1.1
Montando uma biblioteca de fragmentos utilizando o Mira 3.4
Vamos primeiro demonstrar como fazer a montagem utilizando somente um arquivo de fragmentos.
Iniciando pela geração do arquivo fastq:
sff_extract
-s frag_in.iontor.fastq
-x frag_traceinfo_in.iontor.xml
C11-127_40X.sff
1 http://www.sanger.ac.uk/resources/software/caf/
56
Note que o nome do projeto é frag. Em seguida, execute o Mira com o seguinte comando:
mira
--project=frag
-GE:not=4 -OUT:ora=1
IONTOR_SETTINGS -AS:mrpc=100
Em relação ao comando apresentado na seção anterior, adicionamos as opções específicas de cada
plataforma, para isso colocamos IONTOR_SETTINGS seguido das opções para o Ion Torrent, no caso
-AS:mrpc=100 que diz para filtrar todos os contigs com menos de 100 reads.
6.1.2
Montando uma biblioteca de mate-pair utilizando o Mira 3.4
tag1
IA
tag2
Figura 6.1: Estrutura do read de mate-pair do Ion Torrent
Na figura 6.1 vemos a estrutura do read gerado pela técnica de mate-pair no Ion Torrent. Pela construção
temos a tag1 seguida pelo adaptador interno (IA) e a tag2 . O sentido de leitura está indicado pela seta.
Por conta dessa estrutura é preciso separar as tags utilizando a sequência do adaptador interno, o que é
feito na conversão de sff para fastq. O sff_extract utiliza o mapeador SSAHA2 para mapear o IA e
gerar as tags. Portanto, é preciso instalar o SSAHA2, que está disponivel em:
http://www.sanger.ac.uk/resources/software/ssaha2/
É preciso colocar os programas SSAHA2 no path e em seguida utiliza-se o seguinte comando para
gerar os arquivos:
sff_extract
-l LMP_Linkers.fasta
-s lmp35_in.iontor.fastq
-x lmp35_traceinfo_in.iontor.xml
FRA-257_40X.sff
A opção -l fornece um arquivo com a sequência do IA e do seu reverso complementar, no caso, para
o Ion Torrent as sequências são:
>IA
CTGCTGTACCGTACATCCGCCTTGGCCGTACAGCAG
>IA_revcom
CTGCTGTACGGCCAAGGCGGATGTACGGTACAGCAG
mira
--project=frag
-GE:tismin=3000 -GE:tismax=4000
6.1.3
Fazendo uma montagem mista com o Mira 3.4
Agora vamos montar a biblioteca de fragmentos junto com as duas bibliotecas de mate-pair. Para isso
vamos iniciar o processo extraindo os reads de fragmentos:
sff_extract
-s mix_in.iontor.fastq
-x mix_traceinfo_in.iontor.xml
C11-127_40X.sff
57
Em seguida, vamos extrair os dados de primeira biblioteca de mate-pair, devemos prestar muita
atença à opção -a, que pede para que os novos reads extraídos sejam anexados ao arquivo criado na
etapa anterior.
sff_extract
-a -l LMP_Linkers.fasta
-i "insert_size:3500,insert_stdev:500"
FRA-257_40X.sff
Outro ponto importante é a opção -i, que adiciona as informações do inserto ao arquivo XML, no
caso nós adicionamos o tamanho do inserto e o desvio padrão deste, respectivamente, 3500 e 500 bp.
Repetimos o mesmo processo com a segunda biblioteca de mate-pair, no caso alterando o tamanho do
inserto para 8900 bp.
sff_extract
-a -l LMP_Linkers.fasta
-i "insert_size:8900,insert_stdev:500"
C28-140_40X.sff
Por fim, executamos a montagem com o mesmo comando do mira:
mira
--project=frag
Note que não informamos o tamanho do inserto pois essa informação já está embutida no arquivo
xml. O resultado de todas as configurações de montagem para o Mira 3.4 está na tabela 6.1.
frag
LMP 3.5
LMP 8.9
todos
Contigs Grandes
Número de contigs
Consenso
Cobertura (%):
Maior Contig
N50
N90
N95
76
4,606,198
98%
358,908
119,555
41,691
31,604
1,617
4,878,703
104%
7,696
3,928
1,950
1,223
2,766
4,156,500
89%
26,661
1,950
667
578
349
4,936,678
105%
414,460
167,387
31,608
1,861
Todos
Número de contigs
Consenso
Maior Contig
N50
N90
N95
Leituras Utilizadas
76
4,606,198
358,908
119,555
41,691
31,604
1,085,429
1,716
4,915,162
7,696
3,923
1,869
1,128
2,235,506
5,987
5,133,612
26,661
1,422
334
255
4,384,827
2,753
6,509,621
414,460
126,091
616
506
2,906,577
Tabela 6.1: Resultados das montagens do Mira
6.1.4
Fazendo uma montagem mista com o Mira 3.9
Apesar de ainda estar em desenvolvimento, a versão do Mira 3.9 oferece um melhor suporte a dados do
Ion Torrent além de um novo formato de arquivo de configuração para as corridas, que facilita muito a
execução de corridas que combinam diferentes bibliotecas.
58
Para montar o dataset de fragmentos utiliza-se o seguinte arquivo, chamado frag.manifest. Exemplo:
project = frag
job = genome,denovo,accurate
parameters = -GE:not=4 IONTOR_SETTINGS -AS:mrpc=100
readgroup = fragment
technology = iontor
data = frag_in.iontor.fastq frag_traceinfo_in.iontor.xml
Note que os parâmetros estão definidos no topo do arquivo, mas o nome dos arquivos estão definidos
na seção readgroup em vez de serem determinados pela convenção de nomes. Mantivemos os mesmos
nomes de arquivos dos exemplos do mira 3.4, mas poderíamos tê-los chamado de qualquer outro nome
que quiséssemos. Para executar a montagem digita-se o comando:
mira frag.manifest
O uso do arquivo de configuração se torna mais útil quando temos mais de um readgroup:
project = mix
job = genome,denovo,accurate
parameters = -GE:not=4 IONTOR_SETTINGS -AS:mrpc=100
readgroup = frag
data = C11-127_40X.fastq C11-127_40X.xml
technology = iontor
readgroup = lmp89
data = C28-140_40X.fastq C28-140_40X.xml
technology = iontor
templatesize = 8328 9774
segmentplacement = ---> --->
readgroup = lmp35
data = FRA-257_40X.fastq FRA-257_40X.xml
technology = iontor
templatesize = 3075 3863
segmentplacement = ---> --->
Note que definimos 3 readgroups, um para cada tipo de biblioteca. Definimos também o intevalo
válido para o tamanho do inserto das bibliotecas de mate-pair, assim como a sua orientação. Veja que
dessa vez utilizamos uma convenção de nomes completamente diferente, algo que não seria possível no
mira 3.4.
Na tabela 6.2 podemos ver os resultados da montagem de diferentes combinações de bibliotecas.
Number of contigs: Total consensus: Largest contig: N50 contig size: N90 contig size: N95 contig
size:
6.1.5
Interpretando os resultados
Na tabela 6.1 vemos os resultados da montagem para as diferentes bibliotecas e também a montagem
mista que utiliza todas elas. As estatísticas estão divididas em duas seções: “Contigs Grandes” e “Todos”.
A primeira mostra as estatísticas somente dos contigs com mais de 500 bp e que satisfazem certos critérios
de cobertura, já a segunda seção mostra as estatísticas de todos os contigs gerados, independentemente do
tamanho e da cobertura2 . Para avaliar a montagem podemos começar olhando para o “Total Consensus”,
para verificar se o valor está de acordo com o tamanho esperado do genoma. Em seguida, verifica-se o
2 Com
exceção dos contigs filtrados pelos critérios estabelecidos no momento da montagem
59
frag
lmp35
lmp35 + frag
lmp89
lmp89 + frag
Contigs Grandes
Número de Contigs
Consenso
Cobertura (%)
Maior contig
N50
N90
N95
79
4,633,751
99,9%
231,197
93,793
35,799
26,409
223
4,573,815
98,6%
188,021
40,235
11,397
7,035
55
4,632,400
99,8%
590,852
204,781
46,501
36,041
348
4,562,390
98,3%
99,306
30,520
5,929
3,710
54
4629,730
99,8%
540,324
185,223
55,558
45,094
Todos
Número de Contigs
Consenso
Cobertura (%)
Maior Contig
N50
N90
N95
Leituras utilizadas
79
4,633,751
99,9%
231,197
93,793
35,799
26,409
1,022,516
260
4,585,603
98,8%
188,021
40,235
11,378
6,703
2,302,069
146
4,770,620
102,8%
590,852
179,289
40,957
32,292
3,246,379
410
4,586,296
98,8%
99,306
30,520
5,811
3,502
2,319,887
104
4,714,793
101,6%
540,324
185,146
51,490
41,464
3,300,475
Tabela 6.2: Resultados da montagem do Mira 3.9
número total de contigs. Quanto maior esse número, mais fragmentada está a montagem e mais “gaps”
ela apresenta.
Outra estatística muito importante são os Nxx: N50, N90 etc. O N50 representa o tamanho do
contig tal qual 50% do “Total Consensus” está representado por contigs iguais ou de mesmo tamanho.
De maneira similar se define o N90, o N95 ou qualquer outro que se queira. Na figura 6.2 vemos o gráfico
da soma dos tamanhos dos contigs: do maior para o menor, estão indicados os pontos em que a soma
do tamanho representa 50%, 90% e 95% da soma total, e os respectivos valores de N50, N90 e N95. O
N50 é normalmente reportado nas publicações que tratam de montagem de genomas porque ele é um
compromisso entre a capacidade do montador de gerar grandes contigs mas também em não fragmentar
muito o genoma.
Analisando os dados da tabela 6.2, vemos que a combinação de uma biblioteca de mate-pair com
uma de fragmentos gera contigs maiores (o N50 aumenta aproximadamente 5×), e um número menor de
contigs grandes. Por outro lado, se olharmos para os dotplots gerados para todos esses datasets (6.3),
vemos que o número de contigs que se alinham fora da diagonal aumenta, o que indica um maior número
de misassemblies.
6.1.6
Comparando a montagem com uma referência
Quando se faz a montagem de um genoma conhecido, é possível avaliar a qualidade de montagem
alinhando os contigs contra esse genoma. Uma ferramenta para fazer isso é o MUMmer, disponível em:
http://mummer.sourceforge.net/
Utiliza-se para fazer o alinhamento o comando nucmer, que é um alinhador muito rápido para um
pequeno conjunto de sequências:
nucmer -maxmatch -c 100 -p <name> ref.fasta conrigs.fasta
Esse comando vai gerar um arquivo chamado <name>.delta que contém todos, alinhamentos entre os
contigs e a referência codificados em um formato compacto, propício para o processamento por software.
Ou seja, não é um formato para ser visualizado diretamente por pessoas. As opção -maxmatch pede para
o programa tentar todas as ancôras de alinhamento, mesmo se elas não forem únicas, e a opção -c 100
pede para remover alinhamentos muito curtos, com menos de 100bps.
Em seguida, utiliza-se o comando delta-filter para filtrar os alinhamentos e tornar a visualização mais
simples:
delta-filter -r <name>.delta > <name>.delta.r
60
Assembly Statistics
105
4,750,000
100
4,500,000
95
4,250,000
90
4,000,000
85
3,750,000
75
3,500,000
70
3,250,000
65
3,000,000
60
2,750,000
55
2,500,000
50
2,250,000
N95=30,290 bp
N90=36,060 bp
45
2,000,000
40
1,750,000
35
1,500,000
30
1,250,000
N50=119,186 bp
25
1,000,000
20
750,000
15
10
500,000
5
250,000
0
0
0
5
10
15
20
25
30
35
40
45
50
55
60
65
70
75
80
Contig Number
Figura 6.2: Gráfico da soma do tamanho dos contigs para o dataset de fragmentos.
A opção -r diz para o programa escolher o melhor alinhamento em relação à referência. É possível
também filtrar pelo tamanho do alinhamento, com a opção -l. Por exemplo, -l 1000 vai mostrar
somente os alinhamentos 1kbp ou mais.
Por fim utilize o comando mummerplot para gerar o gráfico de comparação dos contigs contra a
referência:
mummerplot -large -layout -p <name> <name>.delta.r
O mummerplot utiliza o gnuplot para gerar os gráficos, por isso é necessário que esse programa esteja
instalado. Também é possível gerar um arquivo de imagem com a opção --png ou um Postscript com
--ps. Podemos ver o resultado do mmumerplot na figura 6.4.
6.1.7
Visualizando a montagem no Tablet
É possível visualizar a montagem dos contigs, ou seja, a posição de cada read nos contigs, utilizando o
programa Tablet[22], que está disponível em:
http://bioinf.scri.ac.uk/tablet/
Esse programa possui instalador gráfico e suporta alguns formatos de alinhamento, entre eles o
formato ACE que pode ser gerado pelo Mira com a opção -OUT:ora=1. Caso o Mira não tenha rodado
com essa opção, é fácil converter o arquivo .maf em .ace com o comando:
convert_project
-f maf -t ace <input>.maf <output>
Tendo o arquivo .ace basta clicar em “Open Assembly” e escolhê-lo na janela de diálogo. No painel
da esquerda está a lista de contigs. Quando se clica em um deles o painel central mostra os alinhamentos
(ver figura 6.5).
61
Cumulative Length
Cumulative Length (%)
80
+ Frag
Frag
3.5 kbp
8.9 kbp
Figura 6.3: Dotplot de todas as bibliotecas montadas com o mira 3.9. Na primeira coluna vemos o dotplot
das bibliotecas de fragmentos, LMP 3.5kbp e LMP 8.9 kbp, e na segunda coluna vemos a combinação
desses bibliotecas junto com a de fragmentos.
62
Figura 6.4: Dotplot da montagem do dataset de fragmentos deita pelo mummerplot.
Figura 6.5: Visualizador de montagem Tablet
63
64
Capítulo 7
Apêndices
7.1
Ordem dos genótipos
O formato VCF define a seguinte expressão para ordenar os genótipos nos campos GL e PL:
F (j, k) = k ∗ (k + 1) + j
(7.1)
Para aplicar a fórmula, associamos a base da referência com o valor 0, e as bases alternativas com os
valores 1, 2, 3, .... Depois, geramos todos os pares distintos (para uma combinação A,B e B,A, mantemos
somente A,B) e os ordenamos de acordo com a função F . A ordem para 2,3 e 4 genótipos é:
2 AA, AB, BB
3 AA, AB, BB, AC, BC, CC
4 AA, AB, BB, AC, BC, CC, AD, BD, CD, DD
Por exemplo, se a referência for A e a variante for T, a ordem dos genótipos é:
AA,AT,TT
E se a referência for A e os genótipos as variantes forem C e T, a ordem é:
AA,AT,TT,AC,CT,CC
7.2
Pileup format
Podemos pensar que o arquivo BAM é organizado em torno dos reads, mas muitas vezes estamos interessados na informação de alinhamento base-a-base. O formato pileup faz uma representação texto
organizada em torno das posições genômicas. Em outras palavras, para cada base do genoma ele “empilha” as bases dos reads. O resultado é uma tabela como a mostrada abaixo:
ecoli 1 A 7
^b.^‘.Ô,Ê,^D,Â,^J, 9?4===5
ecoli 2 G 8
..,,,,,^t,
9?)===-)
ecoli 3 C 10 ..,,,,,,^w.^>.
5?,=7=5)B8
ecoli 4 T 10 ..,,,,,,..
5?$(&(($B8
ecoli 5 T 13 ..,,,,,,..^j.^j,Ê,
5?4=7=5)B8;!!
ecoli 6 T 13 ..,,,,,,...,,
5?4=7=5)B8;!!
ecoli 7 T 13 ..,,,,,,...,,
((4=7=5)((2!!
ecoli 8 C 14 ..,,,,,,...,,^g.
:?6=7=5)>1=!!=
ecoli 9 A 15 ..,,,,,,...,,.^w.
;?6;975+A4;!!=A
O significado de cada coluna é o seguinte:
1. Contig: Nome do contig/cromossomo
2. Posição: Posição no contig/cromossomo (iniciando em 1)
3. Referências: Base na referência
4. Reads: Número de reads mapeados na posição
5. Bases: Esse é o campo mais complexo do arquivo, os símbolos têm os seguintes significados:
65
• . Indica que o read possui a mesma base que a referência
• , Indica que o read possui a mesma base na fita reversa da referência
• ACGTN Indica uma troca pela base indicada
• acgtn Indica uma troca pela base indicada na fita reversa
• +[num][bases] Indica uma inserção de tamanho [num], com as bases [bases]. Por exemplo:
+2AG representa uma inserção das bases AG, já +2AGTC representa uma inserção das bases
AG seguida de duas substituições
• -[num][bases] Indica uma deleção de tamanho [num], com as bases [bases]. Por exemplo:
-2AG representa a deleção das bases AG.
• ^[Q] Indica o início do read, o caracter seguinte ao ^ indica o mapping quality em codificação
fastQ
• $ Indica o final do read
6. Qualidades: Qualidade das bases em codificação fastQ
Para gerar o pileup de um BAM utiliza-se o comando mpileup do samtools da seguinte maneira:
samtools mpileup -f <referencia> <align.bam> > result.pileup
Se o arquivo possuir regiões com cobertura muito alta, é preciso especificar o parâmetro -d <max cov>,
cujo default é 250.
7.3
Samtools VCF file
O resultado do comando mpileup do samtools não é uma lista de SNPs, mas sim um BCF intermediário
que será utilizado para fazer a chamada. Nesse arquivo, vale ressaltar o campo I16, que é uma lista de 16
estatísticas que podem ser utilizadas no variant calling (tabela 7.1). Nessa tabela vemos a quantidade de
bases que concordam com a referência e as que estão diferentes da referência (non-ref) em ambas as fitas,
vemos também as somas das qualidades ref e non-ref, a soma dos quadrados das qualidades, também
vemos a soma dos mapping qualities e os quadrados dos mapping qualities. Nos últimos campos temos
a soma tail-distance, que é a distância da posição do read em relação aos extremos dele. Suponha a base
na posição k do read de comprimento l, a tail distance nesse caso é min(k, l − k).
Também podemos ver uma coluna chamada FORMAT, seguida por uma coluna para cada amostra.
A coluna FORMAT descreve o formato da informação de genótipo e nas colunas seguintes temos os
valores de genótipo para cada amostra. No caso temos o formato PL, que mostra a probabilidade de
cada genótipo em escala phred. A ordem dos genótipos é definida pelo formato VCF. Para mais detalhes
veja a seção5.1.
66
Pos.
1
2
3
4
Descrição
number of
number of
number of
number of
reference Q13 bases on the forward strand
reference Q13 bases on the reverse strand
non-ref Q13 bases on the forward strand
non-ref Q13 bases on the reverse strand
5
6
7
8
sum
sum
sum
sum
of
of
of
of
reference base qualities
squares of reference base qualities
non-ref base qualities
squares of non-ref base qualities
9
10
11
12
sum
sum
sum
sum
of
of
of
of
ref mapping qualities
squares of ref mapping qualities
non-ref mapping qualities
squares of non-ref mapping qualities
13
14
15
16
sum
sum
sum
sum
of
of
of
of
tail distance for ref bases
squares of tail distance for ref bases
tail distance for non-ref bases
squares of tail distance for non-ref
Tabela 7.1: Descrição dos valores do campo I16 gerado pelo samtools mpileup
7.4
Script para converter os nomes dos cromossomos em um
arquivo VCF
Código do script addchr.pl, utilizado para mudar o nome dos cromossomos no arquivo VCF do dbSNP:
#!/usr/bin/env perl
sub addchr {
my $line=shift;
if($line =~ /^(\d+|X|Y)/) {
$line="chr$line";
}elsif($line =~ /^MT/) {
$line =~ s/(^MT)/chrM/;
}
return $line;
}
while(<>) {
if(/^#/) {
if (/##contig=<ID=(.*?),(.*)/) {
#
print "1=$1 2=$2\n";
print "##contig=<ID=",addchr($1),",$2\n";
} else {
print;
}
} else {
print addchr($_);
}
}
67
68
Referências
69
70
Lista de Figuras
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
Evolução do custo de sequenciamento por megabase. Fonte: http://www.genome.gov/
sequencingcosts/. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Processo da amostra de Long Mate Pair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Reação de incorporação de uma base pela polimerase. . . . . . . . . . . . . . . . . . . . . 8
Flowgram da sequência AATCTTCGT... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Estrutura da probes utilizadas pelo SOLiD . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Algumas etapas do processo de sequenciamento: ligação do primeiro primer. . . . . . . . . 10
Algumas etapas do processo de sequenciamento: Ligação do segundo primer. . . . . . . . 12
Esquema de cobertura do template pelos probes para uma leitura de 25 bp. . . . . . . . . 13
2.1
Gráfico da função que calcula o Phred Score . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1
3.2
3.3
3.4
3.5
3.6
Exemplos de alinhamentos e os respectivos registros em formato SAM[18]. . . . . . . . . .
Sensitividade dos algortmos do tmap e do bowtie2 (Amostra de E. Coli O104H4) . . . . .
Performance dos algoritmos do tmap (Amostra de E. Coli O104H4) . . . . . . . . . . . . .
IGV mostrando os alinhamentos do reads na região do gene MTRR . . . . . . . . . . . . .
IGV mostrando os alinhamentos dos reads na região do gene MTRR . . . . . . . . . . . .
Popup boxes do IGV. A) Popup que aparece quando se deixa o cursor sobre um dos reads.
B) popup mostrado quando se deixa o cursor sobre o gráfico de cobertura. . . . . . . . .
IGV com os alinhamentos no modo colapsado. Destaque para duas posições com trocas
de nucleotídeos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
31
32
36
37
4.1
4.2
4.3
4.4
Exemplo de arquivo bedDetail . . . . . . . . . . .
UCSC Table Browser site . . . . . . . . . . . . .
Escolha de regiões ao exportar arquivo BED . . .
Diferença entre os tipos de arquivos BED gerados
.
.
.
.
40
42
42
44
6.1
6.2
6.3
Estrutura do read de mate-pair do Ion Torrent . . . . . . . . . . . . . . . . . . . . . . . .
Gráfico da soma do tamanho dos contigs para o dataset de fragmentos. . . . . . . . . . . .
Dotplot de todas as bibliotecas montadas com o mira 3.9. Na primeira coluna vemos o
dotplot das bibliotecas de fragmentos, LMP 3.5kbp e LMP 8.9 kbp, e na segunda coluna
vemos a combinação desses bibliotecas junto com a de fragmentos. . . . . . . . . . . . . .
Dotplot da montagem do dataset de fragmentos deita pelo mummerplot. . . . . . . . . . .
Visualizador de montagem Tablet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
61
3.7
6.4
6.5
71
. . .
. . .
. . .
pelo
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
UCSC Table Browser.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
62
63
63
72
Lista de Tabelas
1.1
1.2
1.3
1.4
Relação entre a razão beads/fragmentos,
bilidade de empty beads. . . . . . . . . .
Codificação das cores em números. . . .
Leitura de bases pelas probes do SOLiD
Codificação de bases para cores . . . . .
a probabilidade de
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
2.1
2.2
2.3
Código IUPAC para representar o DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Valores de qualidade phred, probabilidades de erro e acurácia . . . . . . . . . . . . . . . . 16
Conversores de SFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
3.2
3.3
3.4
3.5
Headers do arquivo SAM . . . . . . . . . . . . . . .
Alinhamento no arquivo SAM . . . . . . . . . . . . .
Significado e valor de cada flag do format SAM. . . .
Argumentos comuns a todos os comandos do Picard.
Algoritmos do TMAP . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
29
30
5.1
5.2
5.3
5.4
Exemplo de lista de variantes em arquivo VCF (parte obrigatória). . . .
Exemplo de lista de variantes em arquivo VCF (definição de genótipos).
Lista de parâmetros para Torrent Suite Variant Caller (TSVC) . . . . .
Lista de efeitos preditos pelo snpEff . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
51
53
6.1
6.2
Resultados das montagens do Mira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Resultados da montagem do Mira 3.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1
Descrição dos valores do campo I16 gerado pelo samtools mpileup . . . . . . . . . . . . . . 67
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
beads policlonais
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
e
.
.
.
.
a
.
.
.
.
proba. . . . . 8
. . . . . 11
. . . . . 11
. . . . . 12
74
Referências Bibliográficas
[1] P. Bergveld. Thirty years of isfetology: What happened in the past 30 years and what may happen
in the next 30 years. Sensors and Actuators B: Chemical, 88(1):1 – 20, 2003. ISSN 0925-4005.
doi: 10.1016/S0925-4005(02)00301-5. URL http://www.sciencedirect.com/science/article/
pii/S0925400502003015.
[2] B Chevreux, T Pfisterer, B Drescher, A J Driesel, W E G Müller, T Wetter, and S Suhai. Using
the miraEST assembler for reliable and automated mRNA transcript assembly and SNP detection
in sequenced ESTs. Genome Research, 14(6):1147–1159, 2004.
[3] D Earl, K Bradnam, J S John, A Darling, D Lin, J Fass, H O K Yu, V Buffalo, D R Zerbino, and
M Diekhans. Assemblathon 1: A competitive assessment of de novo short read assembly methods.
Genome Research, 21(12):2224–2241, 2011.
[4] Karen Eilbeck, Suzanna E Lewis, Christopher J Mungall, Mark Yandell, Lincoln Stein, Richard
Durbin, and Michael Ashburner. The Sequence Ontology: a tool for the unification of genome
annotations. Genome Biol, 6(5):R44, 2005.
[5] B Ewing, L D Hillier, M C Wendl, and P Green. Base-calling of automated sequencer traces
usingPhred. I. Accuracy assessment. Genome Research, 8(3):175–185, 1998.
[6] Paolo Ferragina and Giovanni Manzini. An experimental study of an opportunistic index. Society
for Industrial and Applied Mathematics, January 2001.
[7] UCSC Genome. Bed format. http://genome.ucsc.edu/FAQ/FAQformat#format1, 2012.
[8] The SAM Format Speciation Working Group. The sam format speciation (v1.4-r985). http:
//samtools.sourceforge.net/SAM1.pdf, 2012.
[9] Broad Institute. Picard faq.
title=Main_Page, 2012.
http://sourceforge.net/apps/mediawiki/picard/index.php?
[10] D Karolchik, A S Hinrichs, T S Furey, K M Roskin, C W Sugnet, D Haussler, and W J Kent. The
UCSC Table Browser data retrieval tool. Nucleic Acids Research, 32(suppl 1):D493–D496, 2004.
[11] B. Langmead, C Trapnell, M. Pop, and S L Salzberg. Ultrafast and memory-efficient alignment of
short DNA sequences to the human genome. Genome Biol, 10(3):R25, 2009.
[12] Ben Langmead and Steven L Salzberg. Fast gapped-read alignment with Bowtie 2. Nat Meth, 9(4):
357–359, March 2012.
[13] Ben Langmead, Michael C Schatz, Jimmy Lin, Mihai Pop, and Steven L Salzberg. Searching for
SNPs with cloud computing. Genome Biol, 10(11):R134, 2009.
[14] H Li. Exploring single-sample SNP and INDEL calling with whole-genome de novo assembly.
Bioinformatics, 28(14):1838–1844, July 2012.
[15] H Li and R Durbin. Fast and accurate short read alignment with Burrows-Wheeler transform.
Bioinformatics, 25(14):1754–1760, July 2009.
[16] H Li and R Durbin. Fast and accurate long-read alignment with Burrows–Wheeler transform.
Bioinformatics, 26(5):589–595, 2010.
75
[17] H Li, J Ruan, and R Durbin. Mapping short DNA sequencing reads and calling variants using
mapping quality scores. Genome Research, 18(11):1851–1858, November 2008.
[18] H Li, B Handsaker, A Wysoker, T Fennell, J Ruan, N Homer, G Marth, G Abecasis, R Durbin,
and 1000 Genome Project Data Processing Subgroup. The Sequence Alignment/Map format and
SAMtools. Bioinformatics, 25(16):2078–2079, August 2009.
[19] R Li, Y Li, K Kristiansen, and J Wang. SOAP: short oligonucleotide alignment program. Bioinformatics, 24(5):713–714, February 2008.
[20] R Li, C Yu, Y Li, T W Lam, S M Yiu, K Kristiansen, and J Wang. SOAP2: an improved ultrafast
tool for short read alignment. Bioinformatics, 25(15):1966–1967, July 2009.
[21] D Lipman and W Pearson. Rapid and sensitive protein similarity searches. Science, 227(4693):
1435–1441, March 1985.
[22] I Milne, M Bayer, L Cardle, P Shaw, G Stephen, F Wright, and D Marshall. Tablet–next generation
sequence assembly visualization. Bioinformatics, 26(3):401–402, February 2010.
[23] Gordon Moore. Lei de moore. http://en.wikipedia.org/wiki/Moore’s_law, 2012.
[24] NCBI. Standard flow format. http://www.ncbi.nlm.nih.gov/Traces/trace.cgi?cmd=show&f=
formats&m=doc&s=format#sff, 2012.
[25] Z Ning. SSAHA: A Fast Search Method for Large DNA Databases. Genome Research, 11(10):
1725–1729, October 2001.
[26] 1000 Genomes Project. Variant call format specification version 4.1. http://www.1000genomes.
org/wiki/Analysis/Variant%20Call%20Format/vcf-variant-call-format-version-41, 2012.
[27] ENCODE Project. Standards, guidelines and best practices for rna-seq. http://encodeproject.
org/ENCODE/protocols/dataStandards/ENCODE_RNAseq_Standards_V1.0.pdf, 2012.
[28] J.C. Roach, C. Boysen, K. Wang, and L. Hood. Pairwise end sequencing: a unified approach to
genomic mapping and sequencing. Genomics, 26(2):345–353, 1995.
[29] Jonathan M Rothberg, Wolfgang Hinz, Todd M Rearick, Jonathan Schultz, William Mileski, Mel
Davey, John H Leamon, Kim Johnson, Mark J Milgrew, Matthew Edwards, Jeremy Hoon, Jan F
Simons, David Marran, Jason W Myers, John F Davidson, Annika Branting, John R Nobile, Bernard P Puc, David Light, Travis A Clark, Martin Huber, Jeffrey T Branciforte, Isaac B Stoner,
Simon E Cawley, Michael Lyons, Yutao Fu, Nils Homer, Marina Sedova, Xin Miao, Brian Reed,
Jeffrey Sabina, Erika Feierstein, Michelle Schorn, Mohammad Alanjary, Eileen Dimalanta, Devin
Dressman, Rachel Kasinskas, Tanya Sokolsky, Jacqueline A Fidanza, Eugeni Namsaraev, Kevin J
Mckernan, Alan Williams, G Thomas Roth, and James Bustillo. An integrated semiconductor device
enabling non-optical genome sequencing. Nature, 475(7356):348–352, April 2104.
[30] S L Salzberg, A M Phillippy, A Zimin, D Puiu, T Magoc, S Koren, T J Treangen, M C Schatz,
A L Delcher, and M Roberts. GAGE: A critical evaluation of genome assemblies and assembly
algorithms. Genome Research, 22(3):557–567, 2012.
[31] Lincoln Stein. http://www.sequenceontology.org/gff3.shtml, February 2013.
[32] Cole Trapnell, Lior Pachter, and Steven L Salzberg. TopHat: discovering splice junctions with
RNA-Seq. Bioinformatics, 25(9):1105–1111, April 2009.
[33] D. Wheeler and M Burrows. A block-sorting lossless data compression algorithm. Digital Systems
Research Center Report, 124, 1994.
76

from lvaruzza.com - Leonardo Varuzza`s Site

Transcrição

Documentos relacionados

Tratamento inicial de sequências

Introdução à análise de dados de sequenciadores de nova geração

Baixar este arquivo PDF

DNA fóssil reconta origem dos cavalos, clique aqui

McLanche Feliz encanta consumidores com clássicos da Hanna

A tecnosfera, o humano obsoleto e o discurso da pós

Tecnologias da reprodução

Reads

Boletim - Fazenda da Esperança

Inglês - Colégio dos Santos Anjos

janeiro MULT.pmd

“Llorando se Foi” O museo da