Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Plataforma Interativa de Análise de
Velocidade em Dados Sísmicos usando GPUs
Gabriel de Almeida Araújo
Natal-RN Julho, 2018
Plataforma Interativa de Análise de Velocidade em
Dados Sísmicos usando GPUs
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Linha de pesquisa:
Processamento Gráfico e Inteligência Com-putacional
Orientador
Prof. Dr. Bruno Motta de Carvalho
Co-orientador
Prof. Dr. Carlos César Nascimento da Silva
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Julho, 2018
Araújo, Gabriel de Almeida.
Plataforma interativa de análise de velocidade em dados sísmicos usando GPUs / Gabriel de Almeida Araújo. - 2018. 80f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Programa de Pós-Graduação em Sistemas e Computação. Natal, 2018.
Orientador: Bruno Motta de Carvalho.
Coorientador: Carlos César Nascimento da Silva.
1. Geofísica - Dissertação. 2. Análise de velocidade sísmica - Dissertação. 3. GPU - Dissertação. 4. CUDA - Dissertação. I. Carvalho, Bruno Motta de. II. Silva, Carlos César Nascimento da. III. Título.
RN/UF/CCET CDU 550.3
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
A Deus por ter me concedido força e resiliência nessa empreitada.
A minha esposa, Erianna Yadja, pelo amor, paciência, compreensão durante essa longa jornada. Essa conquista é nossa.
Aos meus pais, João e Edilene, pela educação, amor e por sempre me mostrarem o caminho correto, sem vocês eu não chegaria aonde estou.
Ao meu irmão, Raphael, que sempre esteve ao meu lado me apoiando e aconselhando. Ao Professor Doutor Bruno Motta de Carvalho, meu orientador, agradeço por ter tido paciência, pelos conselhos nos momentos difíceis e por ter acreditado em mim no início desse desafio.
Ao Professor Doutor Carlos César Nascimento da Silva, meu co-orientador, agradeço pelos ensinamento e correções em diversos momentos. A sua ajuda foi imprescindível para esse trabalho.
À CImaGeo, por todo suporte e ter permitido que esse trabalho virasse realidade. Ao DIMAp, que sempre foi solicito quando eu precisei, e por ter disponibilizado o laboratório IMAGINA durante esse trabalho.
À BP e ao Frederic Billette, por terem disponibilizado o dado utilizado nesse trabalho. Por fim, de coração, eu agradeço à todos os mencionados, sem vocês isso não seria possível.
Dados Sísmicos usando GPUs
Autor: Gabriel de Almeida Araújo Orientador: Prof. Dr. Bruno Motta de Carvalho Co-orientador: Prof. Dr. Carlos Cesar Nascimento da Silva
Resumo
Com o avanço da exploração de hidrocarbonetos, a indústria vem buscando continuamente meios de minimizar os riscos exploratórios, onde um desses meios é o aprimoramento das ferramentas utilizadas. Existem três etapas nessa exploração: a aquisição de dados sísmi-cos, o processamento sísmico e a interpretação sísmica. O presente trabalho se situa no processamento sísmico, mais especificamente em uma de suas etapas, a análise de velo-cidade sísmica, que tem como objetivo encontrar o campo de velovelo-cidade mais fidedigno da subsuperfície da terra através de algoritmos conhecidos de análise. Um dos objetivos desse trabalho é a criação de meios para facilitar essa análise de velocidade, através da implementação desses algoritmos de forma que eles funcionem integrados em uma única plataforma. Outro ponto que o avanço da exploração sísmica trouxe foi o aumento consi-derável do volume de dados sísmicos adquiridos e das tecnologias utilizadas, que elevaram consideravelmente a necessidade de computadores mais poderosos e também à busca de soluções de alto poder computacional. Com base nessa necessidade, será apresentada uma nova metodologia de análise de dados sísmicos usando GPUs e os resultados obtidos da sua utilização, mostrando sua viabilidade para acelerar algoritmos geofísicos, em especial algoritmos voltados para à análise de velocidade. Ao final serão discutidos os resultados e feita a comparação de desempenho dos algoritmos paralelos e sequenciais.
Palavras-chave: Análise de Velocidade Sísmica, Campo de Velocidade Sísmica, Sísmica de Reflexão, GPU, CUDA, CVS, Semblance.
Data using GPUs
Author: Gabriel de Almeida Araújo Supervisor: Bruno Motta de Carvalho, D.Sc. Co-supervisor: Carlos César Nascimento da Silva, D.Sc.
Abstract
With the advancement of hydrocarbon exploration, the oil industry has been searching for ways to minimize exploratory risks, with one of these ways being the improvement of the used tools. There are three steps in this exploration: the seismic data acquisition, the seismic processing and seismic interpretation. This work is part of the seismic pro-cessing, more specifically of one of its stages, the seismic velocity analysis, which aims to find the seismic velocity field that offers reliable earth subsurface models through known algorithms of velocity analysis. One of the objectives of this work is the creation of tools to facilitate this velocity analysis by implementing these algorithms so that they work integrated in a single platform of analysis. Another point that this advance brought, was the considerable increase in the volume of seismic data acquired, which led to an increa-sing need of computer procesincrea-sing power. Given this need, we present a methodology for velocity analysis using GPUs and its results, showing the viability of using it to accelerate Geophysics algorithms, particularly algorithms for velocity analysis. Finally, case studies will be presented, showing the performance results of the algorithms in CPU and GPU versions.
Keywords: Seismic Velocity Analysis, Seismic velocity field, Seismic reflection, GPU, CUDA, CVS, Semblance.
2.1 Formação do traço sísmico, onde as ondas refletidas pelas interfaces são registradas pelos geofones em seus respectivos tempos. Adaptado de (
XA-VIER NETO, 2006). . . p. 22
2.2 Sismograma sintético representando uma aquisição 2D, com eixo x re-presentando os receptores e o com eixo y rere-presentando os tempos, mos-trando (a) onda direta, (b) primeira reflexão e (c) múltipla da primeira
reflexão. Fonte: gerado pelo autor. . . p. 23 2.3 Modelo convolucional de um traço sísmico. Adaptado de (KEAREY et al.,
2002). . . p. 24 2.4 Movimento das partículas e deformação elástica causados pela passagem
da onda de corpo. Adaptado de Kearey et al. (2002). . . p. 25 2.5 Movimento das particulas e deformação elástica causados pela passagem
da onda de superfície. Fonte: (MARTÍNEZ-MORENO, 2015). . . p. 26
2.6 Esquema de aquisição fonte comum, onde mostra vários pontos (CMPs) no refletor alvo sendo amostrados mais de uma vez. Fonte: (CONEGO
JUNIOR, 2009). . . p. 27
2.7 Exemplo de aquisição com multiplicidade para o mesmo ponto em
sub-superfície. Fonte: gerado pelo autor. . . p. 28 2.8 Sismograma correspondente a Figura 2.7. Fonte: gerado pelo autor. . . p. 28 2.9 Modelo de camadas planas horizontais e homogêneas. Adaptado de (
YIL-MAZ, 2001). . . p. 30
2.10 Busca da velocidade para um agrupamento CMP. Adaptado de (TANER;
KOEHLER, 1969). . . p. 31
2.11 Representação do semblance calculado a partir do CMP 500, utilizando a faixa (range) de velocidades de 1000m/s a 5000m/s. Fonte: gerado pelo
autor usando o dado Marmousi. Fonte: gerado pelo autor. . . p. 34 2.13 Cubo representando todas as seções sísmicas empilhadas com velocidade
constante. Fonte: gerado pelo autor. . . p. 35 2.14 Seções sísmicas com velocidades de empilhamento constante. A) V=1500m/s
B) V = 3500m/s. Fonte: gerado pelo autor usando o dado Marmousi. . p. 35 2.15 Fit de hipérboles no CMP. Fonte: gerado pelo autor usando o dado
Mar-mousi. . . p. 36 2.16 Correção do NMO no CMP após a seleção de velocidades no semblance.
Fonte: gerado pelo autor usando o dado Marmousi. . . p. 37 3.1 Operações em ponto flutuante por segundo para CPUs e GPUs. Fonte:
(NVIDIA CORPORATION, 2017). . . p. 39
3.2 Largura de memória para CPUs e GPUs. Fonte: (NVIDIA CORPORATION,
2017). . . p. 39 3.3 Comparação das arquiteturas CPU e GPU. Fonte: (NVIDIA
CORPORA-TION, 2017). . . p. 40
3.4 Exemplo de um Streaming Multiprocessor das GPUs com arquitetura
Fermi. Fonte: (NICKOLLS; DALLY, 2010). . . p. 41
3.5 Grid de blocos e bloco de threads. Fonte: (NVIDIA CORPORATION, 2017). p. 44
3.6 Dois tipos de acesso à memória, sendo um acesso coalesced à direita, e um acesso com bank conflicts à esquerda. Fonte: (NVIDIA CORPORATION,
2017). . . p. 46 4.1 Tela inicial da aplicação. Fonte: gerada pelo autor. . . p. 49 4.2 Tela responsável pelo pré-processamento do dado de entrada. Fonte:
ge-rada pelo autor. . . p. 49 4.3 Tela da aplicação onde é feita a análise de velocidade. Nessa tela o
pri-meiro painel é semblance, sendo na sequência o CDP Gathers, CVP e CVS. Dado fornecido pela BP (BILLETTE; BRANDSBERG-DAHL, 2005)
pelo campo de velocidade interpretado até o momento. As linhas pretas representam os CDPs interpretados. Dado fornecido pela BP (BILLETTE;
BRANDSBERG-DAHL, 2005) para uso acadêmico. Fonte: gerada pelo autor. p. 50
4.5 Modelo de fork-join OpenMP. Fonte: (BARNEY, 2017). . . p. 54
5.1 Modelo de velocidade do dado da BP, com 67km no eixo x e 12km no
eixo y. Fonte: gerado pelo autor. . . p. 63 5.2 Seção empilhada do dado da BP, tendo as mesmas dimensões do modelo
de velocidade. Fonte: gerado pelo autor. . . p. 64 5.3 O gráfico apresenta os tempos de execução das versões implementadas
para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor. . p. 68 5.4 O gráfico apresenta o speedup das versões implementadas para cada teste,
usando a GPU GTX 1080. Fonte: gerado pelo autor. . . p. 68 5.5 O gráfico apresenta, em escala logarítmica, os tempos de execução da
Versão 3 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo
autor. . . p. 70 5.6 O gráfico apresenta o speedup da Versão 3 para cada teste, usando a GPU
GTX 1080. Fonte: gerado pelo autor. . . p. 70 5.7 O gráfico apresenta, em escala logarítmica, os tempos de execução da
Versão 4 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo
autor. . . p. 71 5.8 O gráfico apresenta o speedup da Versão 4 para cada teste, usando a GPU
GTX 1080. Fonte: gerado pelo autor. . . p. 72 5.9 O gráfico apresenta os tempos médios gasto para cada GPU em todos os
testes da Tabela 5. Fonte: gerado pelo autor. . . p. 73 5.10 O gráfico apresenta os tempos médios, da Versão 4, gasto para cada GPU
em todos os testes da Tabela 6 , com exceção dos testes 7 e 8 para a GTX
980. Fonte: gerado pelo autor. . . p. 74 5.11 O gráfico apresenta os speedups entre os desempenhos obtidos usando as
1 Qualificadores de função em programas CUDA. . . p. 43 2 Tipos de memória da GPU. . . p. 45 3 Características do conjunto de dados. . . p. 65 4 Detalhes das GPUs utilizadas. . . p. 66 5 Testes executados para o algoritmo do semblance. . . p. 66 6 Testes executados para o algoritmo CVS. O volume CVS foi calculado
levando-se em conta o número de 151 velocidades distintas (faixa de 1500
a 6000m/s com incrementos de 30m/s). . . p. 67 7 Speed UP médio dos testes executados em relação a versão CPU.
Parâ-metros usados: velocidade mínima de 1500 m/s, velocidade máxima de
6000 m/s e incremento de velocidade de 30 m/s. . . p. 69 8 Tempos de execução (em milissegundos) para os testes do Semblance. . p. 73 9 Tempos de execução (em milissegundos) para os testes do CVS Versão 4. p. 73
GPU – Graphics Processing Unit
CUDA – Compute Unified Device Architecture CPU – Central Process Unit
CMP – Common Mid Point CDP – Common Depth Point NMO – Normal Moveout RMS – Root Mean Square CVS – Constant Velocity Stack CVP – Constant Velocity Panel
API – Application Programming Interface
GPGPU – General-purpose computing on graphics processing units UCP – Unidade Central de Processamento
ALU – Arithmetic Logic Unit
SIMD – Single Instruction Multiple Data SM – Streaming Multiprocessor
SIMT – Single-Instruction, Multiple-Thread OpenMP – Open Multi-Processing
1 Exemplo de kernel em CUDA que somam dois vetores. . . p. 43 2 CPU - Cáculo do Semblance - Calcula o semblance para um cdp gathers. p. 52 3 CPU - Cálculo do CVS - Calcula os painéis CVS para todo o dado. . . p. 53 4 OpenMP - Cáculo do Semblance - Calcula o semblance para um cdp
gathers. . . p. 55 5 OpenMP - Cáculo do Semblance - Calcula o semblance para um cdp
1 Introdução p. 18 1.1 Contribuições . . . p. 20 2 Sísmica de Reflexão p. 21 2.1 Ondas Sísmicas . . . p. 24 2.2 Técnica CMP . . . p. 26 2.3 Velocidade Sísmica . . . p. 29 2.4 Análise de Velocidades . . . p. 30 2.4.1 Espectro de velocidade - Semblance . . . p. 32 2.4.2 Constant Velocity Panels - CVP . . . p. 33 2.4.3 Constant Velocity Stack - CVS . . . p. 34 2.4.4 Outros métodos de análise de velocidade . . . p. 36
3 Arquitetura CUDA p. 38 3.1 Arquitetura da GPU . . . p. 40 3.2 Modelo de Programação . . . p. 42 3.2.1 Kernel . . . p. 42 3.2.2 Hierarquia de Threads . . . p. 43 3.2.3 Hierarquia de Memória . . . p. 45 3.2.4 Questões de Performance . . . p. 45 3.3 Trabalhos Relacionados . . . p. 47 4 Implementação p. 48
4.2 Algoritmos Sequenciais . . . p. 51 4.3 OpenMP (do inglês: Open Multi-Processing) . . . p. 54 4.4 CUDA . . . p. 56 4.4.1 Versão 1 . . . p. 57 4.4.2 Versão 2 . . . p. 58 4.4.3 Versão 3 . . . p. 59 4.4.4 Versão 4 - Novo Método . . . p. 60
5 Experimentos e Resultados p. 62 5.1 Dado Sintético . . . p. 62 5.2 Experimentos . . . p. 65 5.3 Resultados . . . p. 67 6 Considerações Finais p. 76 6.1 Trabalhos Futuros . . . p. 78 Referências p. 79
1
Introdução
A exploração sísmica usa ondas elásticas geradas artificialmente para localizar depó-sitos de minerais (incluindo hidrocarbonetos, minérios, água, reservatórios geotérmicos, etc), sítios arqueológicos e obter informações geológicas para engenharia (SHERIFF; GEL-DART, 1995). As companhias de exploração sísmica se utilizam dos métodos sísmicos para
encontrar petróleo e gás natural (hidrocarbonetos). Entretanto, nem todo petróleo/gás encontrado é viável economicamente. A exploração sísmica é uma atividade relativamente nova, tendo começado por volta de 1923, mas que vem superando grandes desafios, como por exemplo na descoberta e exploração de hidrocarbonetos nos reservatórios do pré-sal brasileiro, podendo alguns reservatórios chegarem a 8,000 metros de profundidade.
Com o crescimento da exploração de hidrocarbonetos nos últimos anos, o aprimo-ramento e desenvolvimento das tecnologias aplicadas nessa exploração se tornam cada vez mais necessários para enfrentar os novos desafios. Quanto aos métodos geofísicos co-mumente empregados nessa atividade, podemos dividi-los em três estágios: aquisição, processamento sísmico e interpretação sísmica. Todos os três estágios tem como objetivo a geração, imageamento e análise dos dados sísmicos. O método sísmico de reflexão tem sido usado para delinear a geologia da subsuperfície para fins de pesquisa de exploração de hidrocarbonetos com crescente aceitação (YILMAZ, 2001).
O primeiro estágio, aquisição sísmica, consiste na aquisição de dados sísmicos na área de interesse com finalidade de tentar chegar em uma imagem da subsuperfície da terra. Estes dados podem conter diversos tipos de ruídos além de alguns problemas inerentes aos métodos de exploração utilizados e podem chegar a dezenas de gigabytes dependendo dos parâmetros de aquisição e da dimensão da área de interesse. Nessa dissertação será abordado um dos problemas inerentes, que é a obtenção do campo de velocidade e as formas de encontrá-lo. O segundo estágio, onde esse trabalho se insere, tem como prin-cipais funções o tratamento e apresentação dos dados adquiridos no estágio anterior. O processamento sísmico tem como finalidade a obtenção de imagens fidedignas da subsu-perfície do solo, tentando imagear o contexto geológico presente. Esse estágio pode ter
sua complexidade aumentada devido a vários fatores: tratamentos empregados no proces-samento, volume dos dados processados, presença de ruídos, complexidade da geologia da área em estudo etc. Por último, temos a interpretação dos dados sísmicos, que vai analisar os dados oriundos do processamento junto com outro tipos de dados que vão corroborar a análise dos interpretes para tentar reduzir o risco exploratório de possíveis reservatórios de hidrocarbonetos.
Com ênfase no processamento, existem vários tipos de processos que podem ser apli-cados aos dados sísmicos, a fim de eliminar ruídos, melhorar a imagem final gerada, e corrigir os problemas oriundos da aquisição sísmica, dentre outros. Este trabalho irá focar em uma das principais etapas do processamento, que consiste na determinação do campo de velocidade das rochas em subsuperfície utilizando vários métodos de análise. Devido à importância do campo de velocidade para várias etapas chaves do processamento e interpretação sísmica, faz-se necessário que ele seja o mais fiel possível à geologia da sub-superfície; um campo de velocidade com baixa precisão pode levar à uma interpretação inconsistente, aumentando as incertezas sobre possíveis reservatórios de hidrocarbonetos, com isso elevando o risco exploratório. Sabendo-se da importância de um bom campo de velocidade, a indústria sempre está buscando meios que consigam entregar um campo de velocidade que representa de forma mais fidedigna à geologia.
A exploração de hidrocarbonetos sempre está em busca de avanços tecnológicos, tanto através da necessidade crescente de adquirir e processar volumes de dados sísmicos cada vez maiores, quanto no avanço de tecnologias/algoritmos empregados nela. Com o desen-volvimento dos computadores foi possível obter os resultados desejáveis cada vez mais rápido, o que fez com que a exploração sísmica tivesse um forte crescimento. Entretanto, ainda existem processos com alto custo computacional e que levam dias para serem con-cluídos. Ao mesmo tempo, o uso de processadores gráficos para aumentar o poder com-putacional de computadores também evoluiu, e tiveram ponto crucial em 2006, quando a NVIDIA lançou o CUDA (Compute Unifeid Device Architecture), que é uma solução para executar códigos em linguagem de programação C de forma mais simples na GPU (do inglês Graphics Processing Unit).
Dado o potencial das GPUs, que possuem uma capacidade de processamento elevada com um baixo custo quando comparadas às CPUs (Central Processing Unit), a indústria do petróleo passou a acompanhar de perto o seu avanço e consequentemente a desenvolver soluções para elas. Apesar de já existirem resultados promissores dessas soluções, essa tecnologia ainda é pouco difundida na indústria do petróleo, devido à dificuldade de
programação e sua curva de aprendizagem ser razoavelmente alta. A utilização das GPUs nas mais diversas áreas de aplicação tem feito com que seus preços tenham se tornado cada vez mais acessíveis.
1.1
Contribuições
A presente dissertação tem como uma das contribuições o estudo e implementação de duas técnicas de análise de velocidade existentes na indústria do petróleo em uma única plataforma independente de análise de velocidade, onde será possível ter controle total do dado sísmico visando interpretar um modelo de velocidade coerente com a geologia em estudo. Para tal implementação, utilizaremos a tecnologia CUDA em processos cha-ves que demandam mais tempo computacional, tendo assim um ganho considerável de performance.
As contribuiçòes específicas deste trabalho são:
• Estudo da arquitetura CUDA da NVIDIA, buscando técnicas que possibilitem um ganho de tempo computacional nos algoritmos a serem implementados e compará-los com suas versões em CPU , apresentando possíveis ganhos de desempenho.
• Desenvolvimento de uma plataforma standalone, que integra as técnicas de CVS e Semblance em uma única ferramenta.
• Implementação paralela dos algoritmos CVS e Semblance na arquitetura CUDA. • Estudo da viabilidade da execução dos cálculos necessários para o CVS e Semblance
2
Sísmica de Reflexão
A sísmica de reflexão é um método geofísico utilizado para caracterizar a subsuperfície da terra, tendo como modelo principal a geração de ondas elásticas por meio de fontes artificiais na superfície. Essas ondas viajam pelas camadas da terra e ao encontrarem uma interface entre duas camadas com diferente propriedades físicas elas são refletidas em parte para a superfície, onde podem ser captadas por receptores espalhados pela área em estudo, e outra parte é refratada para as camadas de baixo. Segundo Huyghens (1920), o ponto refratado se torna uma nova fonte (frente de onda). Esse processo acontece sucessivamente, porém só é captado pelos geofones até um determinado tempo.
Os receptores, geofones para aquisições terrestres e hidrofones para aquisições marí-timas, registram o tempo de trânsito com sua amplitude relativa. Esse tempo de trânsito corresponde ao tempo gasto para a onda percorrer as camadas da subsuperfície do solo entre a fonte e o receptor. A Figura 2.1 exemplifica como é feito esse registro. Os tempos de trânsito juntamente com suas amplitudes captadas são digitalizados e registrados no sismógrafo, formando o traço sísmico que corresponde a um par fonte-receptor.
Quanto às dimensões, existem dois tipos de levantamento sísmicos: 2D, onde cada fonte é composta por um conjunto de receptores dispostos em uma única linha, e 3D, onde o conjunto de receptores estão dispostos em 2 ou mais linhas paralelas. Cada con-junto fonte-receptores é registrado no sismógrafo formando um sismograma. A Figura 2.2 representa um sismograma, ele também pode ser representado por uma matriz, onde os receptores estão dispostos nas colunas com um determinado afastamento (offset) fonte-receptor associado e nas linhas estão dispostos as amplitudes e tempos registrados pelos receptores.
Figura 2.1: Formação do traço sísmico, onde as ondas refletidas pelas interfaces são re-gistradas pelos geofones em seus respectivos tempos. Adaptado de (XAVIER NETO, 2006).
Figura 2.2: Sismograma sintético representando uma aquisição 2D, com eixo x represen-tando os receptores e o com eixo y represenrepresen-tando os tempos, mostrando (a) onda direta, (b) primeira reflexão e (c) múltipla da primeira reflexão. Fonte: gerado pelo autor.
O modelo convolucional do traço sísmico pode ser aproximado como a convolução da função de refletividade com a wavelet gerada pela fonte, como apresentado na Figura 2.3 e representado pela Equação 2.1:
S(t) = R(t) ∗ W (t) + r(t), (2.1)
onde S(t) representa o traço sísmico, R(t) representa a função de refletividade, W (t) representa a fonte artificial e r(t) representa o ruído.
da subsuperfície, podendo ser definido matematicamente pela equação: R = V2ρ2− V1ρ1
V2ρ2+ V1ρ1
, (2.2)
onde, Vnrepresenta a velocidade da n-ésima camada, ρnrepresenta a densidade da n-ésima
camada e a Vnρn representa a impedância acústica da n-ésima camada. A Equação 2.2
leva em consideração a incidência normal da onda sísmica, como podemos ver na Figura 2.1. Essa refletividade é a porção de energia que retorna da interface.
Figura 2.3: Modelo convolucional de um traço sísmico. Adaptado de (KEAREY et al., 2002).
2.1
Ondas Sísmicas
Segundo Kearey et al. (2002), as ondas sísmicas são parcelas de energia de deformação elástica que se propagam a partir de uma fonte sísmica, como um terremoto ou uma explosão. Essas ondas viajam pelas camadas com velocidades que dependem do módulo elástico e densidades das rochas, sendo que elas podem ser classificadas em duas categorias, ondas de corpo (body waves) e ondas de superfície (surface waves).
Existem dois tipos de onda de corpo, onda P (primária) e onda S (secundária). A principal característica delas é que nas ondas P, também conhecidas como ondas com-pressionais, as partículas do meio se movem na direção da onda, causando compressão e dilatação do meio; já nas ondas S ou de cisalhamento, as partículas se movem
perpendi-cularmente a direção da onda, e normalmente tem velocidades menores que as ondas P. Devido às ondas S exercerem força de cisalhamento no meio, elas não se propagam em fluidos (gases e líquidos), já que esses meios não suportam esse tipo força. A Figura 2.4 mostra o comportamento dessas ondas no meio.
Figura 2.4: Movimento das partículas e deformação elástica causados pela passagem da onda de corpo. Adaptado de Kearey et al. (2002).
.
As ondas de superfície são divididas basicamente em 2 tipos: Rayleigh e Love. Segundo Sheriff e Geldart (1995), a onda Rayleigh é a mais importante na exploração sísmica, pois ela se propaga ao longo de uma superfície livre de um sólido, com movimento de rolamento. Eles ainda afirmam que devido ao fato de que as constantes elásticas e a densidade do ar serem tão baixas comparadas com as da rocha, o contato entre o solo e o ar pode ser comparado com o de uma superfície livre. Já as ondas Love só existem se o meio não for uniforme. Podemos exemplificar pela situação de quando uma camada é sobreposta por outra de velocidade maior que termina na superfície. A Figura 2.5 mostra o comportamento dessas ondas no meio.
Figura 2.5: Movimento das particulas e deformação elástica causados pela passagem da onda de superfície. Fonte: (MARTÍNEZ-MORENO, 2015).
Na exploração de hidrocarbonetos, as ondas de corpo são as que tem maior relevância nos processos de aquisição, processamento e interpretação sísmica, sendo a onda P a mais utilizada. Porém vale ressaltar que para poder se trabalhar com a onda S é necessário realizar um tipo de aquisição específica, utilizando geofones que consigam captar esse tipo de onda. Já as ondas superficiais são tratadas como geradoras de ruídos, portanto, o seu estudo tem como objetivo a atenuação de ruídos. Este trabalho será focado nas ondas P, onde estão concentradas grande parte do sinal que estamos procurando.
2.2
Técnica CMP
Nos anos 50, as aquisições sísmicas faziam apenas uma leitura dos pontos em sub-superfície, dificultando o imageamento da geologia devido à razão sinal-ruído ser muito baixa. Com o avanço das técnicas de exploração, bem como os equipamentos utilizados, foi criada uma nova técnica chamada Common Midpoint - CMP , também conhecida como (Common Depth Point) - CDP para camadas planas horizontais, que visa aumentar a
multiplicidade1 do ponto imageado em subsuperfície, fazendo com que este ponto tenha
ganhos consideráveis em razão sinal-ruído. Esse aumento da multiplicidade se dá através de dois parâmetros na aquisição sísmica; o primeiro é o número de receptores por ponto de tiro; o segundo é a configuração das distâncias entre fontes e receptores. Na Figura 2.7 podemos ver um exemplo de aquisição sísmica e como a multiplicidade é gerada.
Normalmente a aquisição sísmica é feita por fonte comum, isso significa que para cada fonte gerada no campo, são espalhados receptores com a mesma distâncias entre eles. Note que na Figura 2.6 para cada par fonte-receptor um CMP é associado no ponto médio2.
Um dos maiores custos nas aquisições sísmicas são as fontes artificiais, por esse motivo os dados sísmicos são adquiridos no padrão fonte comum e posteriormente no processamento sísmico, esses dados são reordenados de acordo com o processo utilizado.
Figura 2.6: Esquema de aquisição fonte comum, onde mostra vários pontos (CMPs) no refletor alvo sendo amostrados mais de uma vez. Fonte: (CONEGO JUNIOR, 2009).
A técnica CMP tem como principal objetivo, coletar traços sísmicos que tiveram dife-rentes trajetórias na subsuperfície e com mesmo ponto médio em um único agrupamento, com o intuito de melhorar a razão sinal-ruído por realizar o stacking3 (empilhamento
horizontal) desses traços, onde é possível atenuar consideravelmente os ruídos aleatórios, visto que a soma de ruídos aleatórios de média zero tende a zero, além de aumentar o número de traços sísmicos que enxergam o mesmo ponto em subsuperfície.
1Definida como o aumento de redundância para determinados agrupamentos, neste caso o CMP. 2Definindo como ponto médio a distância entre a fonte e o receptor dividida por dois.
Figura 2.7: Exemplo de aquisição com multiplicidade para o mesmo ponto em subsuper-fície. Fonte: gerado pelo autor.
Figura 2.8: Sismograma correspondente a Figura 2.7. Fonte: gerado pelo autor. Com o aumento da multiplicidade, que introduziu traços sísmicos com diferentes afas-tamentos, também foi possível ter ganhos consideráveis na busca do campo de velocidade das camadas da subsuperfície. Assumindo que a terra tem camadas plano-paralelas e ho-mogêneas, as interfaces entre as camadas irão aparecer como hipérboles de acordo com a Equação 2.3:
t2 = t20+ x
2
v2, (2.3)
onde t0 representa o tempo de percusso de ida e volta até o refletor, x representa o
afastamento fonte-receptor e v a velocidade de propagação da onda nas camadas. Visto que a medida que aumentamos o afastamento entre fonte e receptor aumentamos também o tempo de percurso da onda, esse aumento no tempo é chamado de normal moveout.
2.3
Velocidade Sísmica
A velocidade sísmica é um dos atributos mais importantes na exploração de hidro-carbonetos, pois ela carrega as informações geológicas das camadas em subsuperfície, e tem a sua utilização em várias etapas dessa exploração. Devido a essa importância, a indústria do petróleo sempre está em busca de aprimorar os meios de encontrar o modelo de velocidade.
Existem várias tipos de velocidade sísmicas, dentre elas as que irão ser estudadas nesse trabalho, velocidade de empilhamento (Vs), velocidade root-mean-square (VRM S),
veloci-dade intervalar (Vi), velocidade normal moveout (VN M O). Todas as velocidades citadas
estão relacionadas entre si. Segundo Yilmaz (2001), assumindo um meio de camadas, a velocidade de empilhamento é relacionada a velocidade de NMO , que, por sua vez, está relacionada à velocidade RMS , da qual as velocidades intervalares são derivadas. Essas velocidades serão detalhadas mais à frente nessa seção.
A velocidade é uma das propriedades das camadas geológicas, e existem vários fatores que afetam o seu comportamento: as composições litológicas das rochas em subsuperfície nas quais elas estão percorrendo, como porosidade, pressão dos poros, fluido de saturação dos poros, pressão de confinamento e temperatura. Um dos fatores que mais influenciam a velocidade sísmica é a pressão de confinamento. Ela normalmente aumenta com a pro-fundidade das camadas.
A velocidade que produz uma maior coerência ao empilhar os traços do agrupamento CMP após à aplicação do NMO é denominada de velocidade de empilhamento e a forma mais comum de encontrá-la é através da etapa de processamento sísmico denominada de análise de velocidade. Essa análise será melhor descrita na Seção 2.4 desse trabalho.
Uma maneira de encontrar as velocidades de camadas planas horizontais e com velo-cidade constante, é através da Equação:
VRM Sn = s Pn k=1v2ik∆tk Pn k=1∆tk , (2.4)
onde Vik representa a velocidade intervalar da camada k, com k variando de 1 a n, e
∆tk representa o tempo de transito vertical da camada k. A equação: 2.4 expressa a
velocidade quadrática média (RMS) da n-ésima camada. A Figura 2.9 representa um modelo de camadas citado acima.
Figura 2.9: Modelo de camadas planas horizontais e homogêneas. Adaptado de (YILMAZ,
2001).
DIX (1955) mostrou que podemos chegar nas velocidades intervalares a partir das velocidades RMS mostradas anteriormente utilizando a Equação 2.5:
Vik =
s
tkVk2− tk−1Vk−12
tk− tk−1
, (2.5)
onde, Vk é a velocidade RMS da camada k no tempo de trânsito tk.
A velocidade NMO é aquela que corrige o efeito do afastamento fonte-receptor no agrupamento CMP. Para camadas planas, horizontais e de velocidade constante, ela pode ser comparada a velocidade de empilhamento. Entretanto, para geologia complexas, essa comparação fica inapropriada, necessitando uma correção na velocidade de empilhamento. Todavia, os pacotes de processamento utilizam a velocidade de empilhamento como o modelo inicial e ao longo do processamento ela é corrigida.
2.4
Análise de Velocidades
Segundo Yilmaz (2001), o normal moveout é a base para a determinação do campo de velocidade nos dados sísmicos, e que a partir dessas velocidades, é feita a correção do NMO, fazendo com que os refletores no domínio CMP fiquem alinhados horizontalmente antes do empilhamento. Taner e Koehler (1969) mostraram como a velocidade pode influenciar de forma considerável a qualidade dos refletores imageados. Na Figura 2.10 podemos ver como a velocidade age sobre a amplitude final empilhada, onde as velocidades V1 e V3
geraram, após o empilhamento, amplitudes com baixa energia, e a V2 gerou a de maior
energia. Isso fica claro quando vemos as hipérboles traçadas ao longo da reflexão em T0
para cada uma das velocidades. A busca da velocidade que melhor empilha a hipérbole, nesse caso a V2, geram imagens com mais qualidades e que representam de forma mais
precisa a subsuperfície da terra, diminuindo assim o risco exploratório.
Figura 2.10: Busca da velocidade para um agrupamento CMP. Adaptado de (TANER; KOEHLER, 1969).
Atualmente, na indústria, existem diversos métodos de análise de velocidade. A maio-ria deles assume a velocidade de empilhamento para o cálculo dos tempos de trânsito para cada traço no agrupamento CMP levando em consideração o seu afastamento. Para esse cálculo é utilizada a Equação 2.3 como base. Normalmente, a seleção dessas velocidades é feita pelo geofísico comumente com auxilio do geólogo que tem noção da geologia local. Existem várias tentativas de tornar essa seleção mais automática, no entanto, hoje o que predomina é a seleção feita pelo usuário. Para selecionar (picking) a melhor velocidade são utilizados dois ou mais métodos de análise, dessa forma, corroborando a escolha da velocidade. Existem vários fatores que influenciam esse picking, como o afastamento má-ximo entre o par fonte-receptor, a profundidade do refletor alvo, banda de frequência do sinal, razão sinal-ruído do dado sísmico e quantidade de traços do agrupamento CMP etc. Revorêdo e NASCIMENTO DA SILVA (2016) mostraram que a integração de vários métodos de análise de velocidade pode trazer benefícios na hora da interpretação de dados com baixa cobertura e razão S/R (Signal to Noise Ration - SNR ou S/N). Eles ainda concluíram que o uso simultâneo desses métodos ajuda a diminuir as ambiguidades geradas durante a análise.
Sheriff e Geldart (1995) explicitam que para um usuário realizar o picking, normal-mente, ele é guiado por um conjunto de regras simples: a velocidade de empilhamento provavelmente cresce com a profundidade ao invés de decrescer, eventos sucessivos são se-parados por mais 100ms em tempo duplo, velocidades intervalares maiores que 6700m/s e menores que 1430m/s são improváveis, a diferença em velocidade intervalar para camadas
sucessivas deve exceder 2% e que eventos que tem o dobro do tempos t0 do evento anterior
e com aproximadamente a mesma velocidade, provavelmente indicam uma múltipla e não devem ser usados.
Nesse trabalho serão detalhados alguns métodos de análise de velocidade que foram julgados relevantes para a obtenção do modelo de velocidade, além de gerar um melhor entendimento do problema e como encontrar meios de solucioná-los. Para auxiliar esse en-tendimento os métodos listados a seguir serão detalhados: Costant Velocity Stack-(CVS), Constant Velocity Panel-(CVP), espectro de velocidade-(Semblance) e Horizon Velocity Analysis-(HVA).
2.4.1
Espectro de velocidade - Semblance
Semblance é uma medida de coerência que é feita, normalmente, a partir de um CMP ou supergathers4. Essa medida é feita para todos os tempos do agrupamento em questão
e em todas as velocidades pré-definidas. Esse método equivale a varrer todos os tempos utilizando a Equação 2.3 e com uma lista velocidades, e para cada par tempo-velocidade é calculado o nível de coerência, como podemos ver na Figura 2.10 que mostra a velocidade V2 sendo a que gerou o melhor nível de amplitude para o tempo T0.
Existem diversas técnicas para calcular o semblance, sendo que neste trabalho vamos utilizar a técnica representada pela equação:
S = 1 M P t PM i=1fi,t(i) P t PM i=1f 2 i,t(i) , (2.6)
onde fi,t(i)representa o valor da amplitude no i-ésimo traço no tempo de trânsito t(i) dado
pela Equação 2.3 e M representa o número de traços do agrupamento CMP. A Equação 2.6 é definida com a relação de energia de entrada/saída normalizada (YILMAZ, 2001).
Figura 2.11: Representação do semblance calculado a partir do CMP 500, utilizando a faixa (range) de velocidades de 1000m/s a 5000m/s. Fonte: gerado pelo autor.
A Figura 2.11 mostra um semblance derivado do dado Marmousi (VERSTEEG, 1994).
Neste exemplo o semblance representa de forma satisfatória o trend de velocidades a serem escolhidas. No entanto, quando há uma baixa razão sinal-ruído, o semblance fica prejudicado sendo necessário o auxílio de outros métodos na análise.
2.4.2
Constant Velocity Panels - CVP
O CVP normalmente está relacionado com mais dois métodos de análise, o semblance e o supergathers CMP. Após a introdução da técnica CMP, a exploração sísmica sem-pre buscou aumentar a multiplicidade dos dados sísmicos, mas semsem-pre esbarravam na falta de instrumentos para tal, além do custo financeiro, o que gerava CMPs com baixa multiplicidade o que por sua vez gerava um traço empilhado de baixa razão sinal-ruído. Para tentar aumentar essa razão, criava-se o supergathers, que era usado para aumentar
a multiplicidade temporariamente apenas para analisar velocidade.
Com o supergathers já formado, o método CVP gera para cada velocidade pré definida em uma lista, painéis de CMP empilhados, que são dispostos lado a lado, onde é analisada a melhor velocidade para o refletor alvo. Na Figura 2.12 podemos ver um exemplo de painéis com velocidade constante.
Figura 2.12: Painel com faixas de CMPs com velocidade constante. Fonte: gerado pelo autor usando o dado Marmousi. Fonte: gerado pelo autor.
2.4.3
Constant Velocity Stack - CVS
Esse método consiste em gerar painéis empilhados com velocidade constate dos da-dos sísmicos, a partir da-dos CMPs e da lista de velocidades pré-definida, onde, para cada velocidade definida, todos os agrupamentos CMPs do dado são corrigidos usando NMO e empilhados, formando uma seção sísmica (imagem). Essas seções são dispostas uma atrás da outra em uma ferramenta onde se permite analisar em quais velocidades os refletores alvos têm melhor resolução e qualidade. A Figura 2.13 dá uma ideia de como o método funciona. Na Figura 2.14, a primeira seção empilhada com velocidade de 1500m/s mostra que os refletores mais rasos estão com boa definição e os refletores mais profundos com baixa qualidade. Já na segunda seção, que tem velocidade de empilhamento de 3500m/s, é a situação inversa, onde a velocidade alta empilha de forma mais satisfatória os refletores
mais profundos em detrimento dos rasos. A ideia é navegar entre as seções e analisar para o par tempo × CDP, qual seção (velocidade) é a que mostra o melhor empilhamento.
Figura 2.13: Cubo representando todas as seções sísmicas empilhadas com velocidade constante. Fonte: gerado pelo autor.
Figura 2.14: Seções sísmicas com velocidades de empilhamento constante. A) V=1500m/s B) V = 3500m/s. Fonte: gerado pelo autor usando o dado Marmousi.
Esse método é robusto quanto as variações de velocidade, pois facilita enxergar mu-danças laterais de velocidade com mais precisão, tornando a análise mais completa onde a
complexidade geológica aumenta. Um dos pontos negativos é que ele pode ter um elevado custo computacional se o volume do dado sísmico e a lista de velocidades forem grandes.
2.4.4
Outros métodos de análise de velocidade
Não menos importantes, há diversas outras formas que auxiliam na análise de ve-locidades. Uma delas é o fit de hipérbole, que equivale a desenhar hipérboles no CMP para cada tempo e velocidade selecionada, auxiliando na escolha da hipérbole que melhor representa o refletor no CMP, representado pela Figura 2.15. Outra forma é a horizonta-lização da hipérbole, que consiste em aplicar a correção de NMO no CMP após a seleção das velocidades, ver Figura 2.16.
Figura 2.16: Correção do NMO no CMP após a seleção de velocidades no semblance. Fonte: gerado pelo autor usando o dado Marmousi.
Todos os métodos expostos nesse trabalho ainda são amplamente usados pela indús-tria, mesmo que em diversas vezes alguns deles não estejam incluídos na solução final de cada empresa. Um dos objetivos citados neste trabalho é a integração de todos esses métodos em uma única plataforma, dessa forma, é possível diminuir a ambiguidade inter-pretativa, levando a um campo de velocidade sísmica mais fidedigno reduzindo os riscos exploratórios.
3
Arquitetura CUDA
Até o ano de 1990 ainda não existiam GPUs, apenas controladores gráficos; esses eram utilizados basicamente para gerar gráficos 2D para PCs e não podiam ser programáveis, eram apenas configurados. Eles utilizavam basicamente APIs -(Application Programming Interface), que são camadas de software que utilizam bibliotecas de funções que permitem aplicações usarem serviços e funcionalidades de software ou hardware (KIRK; HWU, 2012).
Em 1999 a NVIDIA lançou as primeiras GPUs programáveis, foi quando a comunidade científica vendo o grande poder computacional das GPUs, passou a utilizá-las não só para renderização gráfica mas também para tarefas de processamento de imagens, visão com-putacional, inteligência artificial, cálculos numéricos, etc. Essa utilização ficou conhecida como GPGPU (General-purpose computing on graphics processing units).
A GPGPU ainda representava um grande desafio para os programadores, pois só era possível utilizar APIs como o OpenGL e DirectX para acessar os recursos computacionais da GPU, tendo que reformular seus problemas em termos gráficos através das funções dessas APIs. Foi então que Buck et al. (2004) apresentaram o Brook, um sistema para GPGPU que estendia a linguagem de programação C para incluir construções simples de dados paralelos, habilitando o uso de GPUs como um co-processador de transmissão. O Brook passou a utilizar conceitos de kernel, streams, etc, o que levou a programa-dores adotarem programação de alto nível para GPU, tornando o uso de GPUs para o processamento mais viável. Contudo, ainda não era fácil escrever códigos para o Brook.
Sabendo do potencial do paralelismo e do poder computacional das GPUs em diversos problemas existentes, a NVIDIA, convidou Ian Buck para juntos chegarem em uma solu-ção mais amigável e prática de rodar programas em C nas GPUs. Em 2006, a NVIDIA disponibiliza o CUDA, a primeira solução de código alto nível para suas GPUs. Com o surgimento do CUDA, o uso das GPUs pela indústria e pesquisadores começou a aumen-tar de forma rápida, passando a ser uma solução extremamente viável, visto que é possível ter ganhos de mais de 100X quando comparamos a soluções em CPU. Nas Figuras 3.1 e 3.2 é mostrado o avanço das GPUs da NVIDIA ao longo do tempo. Fica evidente o quanto
as GPUs avançaram tanto no poder computacional quanto na velocidade de comunicação com as memórias.
Figura 3.1: Operações em ponto flutuante por segundo para CPUs e GPUs. Fonte: (NVIDIA CORPORATION, 2017).
Figura 3.2: Largura de memória para CPUs e GPUs. Fonte: (NVIDIA CORPORATION, 2017).
Nesse capítulo será apresentada de forma mais detalhada a arquitetura CUDA, onde serão mostrados suas principais características, como a arquitetura da GPU, o modelo
de programação com a hierarquia de threads e memórias e formas de obter uma melhor performance.
3.1
Arquitetura da GPU
Quando se compara as arquiteturas das GPUs e CPUs, vemos que elas se diferem em vários pontos. A arquitetura da CPU é composta basicamente por UCP (Unidade Central de Processamento), memória, unidades de entrada/saída e barramento. A memória tem função de armazenar dados e programas (conjunto de instruções), as ULAs ficam a cargo de executar esses programas, as unidades de entrada/saída fazem a comunicação com os componentes externos a CPU e o barramento faz a conexão dos três componentes anteriores. Nota-se que nos computadores atuais de uso doméstico, normalmente, o número de núcleos das CPUs é pequeno, o que acaba restringindo o seu poder de paralelismo. Nas GPUs temos um aumento considerável no número de ALU (Arithmetic Logic Unit), unidades responsáveis principalmente pelos cálculos executados, esse é um dos motivos que levam a GPU à atingir bons níveis de processamento. Na Figura 3.3 ficam evidentes as diferenças entre as arquiteturas.
Com o aumento no número de ALUs dedicadas ao processamento de dados, a GPU foi desenhada para executar processos em paralelos com alta intensidade aritmética, uti-lizando o conceito de SIMD - Single Instruction Multiple Data, que diz que todas as unidades de processamento executam o mesmo conjunto de instruções em diferentes con-juntos de dados.
Figura 3.3: Comparação das arquiteturas CPU e GPU. Fonte: (NVIDIA CORPORATION,
2017).
As GPUs da NVIDIA são construídas como um conjunto escalável de SM - Streaming Multiprocessors, onde cada SM é composto por diversos componentes: as ALUs que estão
contidas nos CUDA-cores, memória compartilhada, registradores, unidades de controle, etc. Quando um código em CUDA (kernel) é executado na GPU um grid de blocos é criado e distribuído para os SMs, cada SM executa em paralelo um bloco que contém x threadse essas threads por sua vez, são executadas concorrentemente no SM. A Figura 3.4 mostra um SM da arquitetura Fermi. Quando um bloco de threads é finalizado, um outro é enviado para o próximo SM disponível, e isso se repete até que não haja mais blocos. Essa forma de lidar com as centenas de threads criadas introduziu um novo conceito denominado de SIMT - Single-Instruction, Multiple-Thread.
Figura 3.4: Exemplo de um Streaming Multiprocessor das GPUs com arquitetura Fermi. Fonte: (NICKOLLS; DALLY, 2010).
3.2
Modelo de Programação
Os programas em CUDA seguem basicamente o mesmo padrão; copiam-se os dados a serem trabalhados para a memória da GPU, é feita a chamada do kernel e após o processamento na GPU o resultado é copiado de volta para a memória do computador. Apesar da forma simples de como foi citado, há grandes desafios no desenvolvimento dos programas para CUDA, desde a cópia de dados para as memórias, tamanho do kernel, adaptação dos programas sequenciais para o paralelismo, divisão do processamento em blocos, definição de padrões de acesso a memória, etc.
O CUDA já é aceito por várias linguagens de programação, tornando-o ainda mais difundido na indústria e nos meios acadêmicos. A NVIDIA disponibiliza todo o material necessário para começar o desenvolvimento, desde um guia de programação, até exemplos de códigos prontos.
3.2.1
Kernel
A função kernel, como foi dito anteriormente, é parte do código escrito em uma lin-guagem suportada (C no caso desse trabalho) e que tem como finalidade realizar algum processamento na GPU. Para exemplificar como um kernel é escrito, foi criado o Algo-ritmo 1, que realiza soma de vetores. Nele é feita a definição do kernel que vai realizar essa soma e logo após, a sua chamada. Essa chamada tem a seguinte configuração: um bloco de threads contendo N threads. Isso quer dizer que o kernel será executado por uma SM e todas as N threads serão executadas ao mesmo tempo. Um dos problemas dessa configuração, é que ela é limitada pelo número máximo de threads por SM, normalmente 1024. Uma solução para esse problema é a criação de blocos de threads. Dessa forma, conseguindo-se aumentar consideravelmente o N.
A sintaxe que define quantos blocos de threads e quantas threads por blocos vão ser executadas na chamada do kernel no caso do Algoritmo 1 é <<< 1, N >>>. Essa é a configuração mais simplista de chamada. A configuração mais completa é definida por <<< Dg, Db, N s, S >>>, onde Dg é o número de blocos a serem executado, Db o número de threads por bloco, Ns o tamanho em bytes da memória compartilhada e S a stream em que o kernel será executado. Os dois últimos parâmetros são opcionais, sendo 0 quando não informados.
Existem 3 tipos de qualificadores de função, __global__ para funções que vão ser chamadas pela CPU para serem executadas na GPU, __host__ para funções que são
Algoritmo 1 Exemplo de kernel em CUDA que somam dois vetores.
1 // Definição do kernel
2 __global__ void SomaVet(float* V1, float* V2, float* R)
3 {
4 int i = threadIdx.x;
5 R[i] = V1[i] + V2[i];
6 }
7 int main()
8 {
9 ...
10 // Chamada do kernel com 1 bloco de N threads
11 SomaVet<<<1, N>>>(V1, V2, R);
12 ...
13 }
chamadas e executadas pela CPU e __device__ para funções chamadas e executadas pela GPU, no entanto a partir da compute capability1 3.2 as funções com o qualificador
__global__ também podem ser chamadas pela GPU. A Tabela 1 resume todos os casos dos qualificadores citados.
Qualificador Chamada pela: Execução pela:
__host__ CPU CPU
__device__ GPU GPU
__global__ CPU e GPU GPU
Tabela 1: Qualificadores de função em programas CUDA.
3.2.2
Hierarquia de Threads
Ao chamar a execução de uma função na GPU um número de threads é criado. Esse número pode chegar a milhões a depender da compute capability da GPU. As threads criadas são divididas em blocos, sendo esses blocos divididos em grids. Tanto os grids de blocos quanto os blocos de threads podem ter até 3 dimensões. Na Figura 3.5 estão representados um grid e um bloco com 2 dimensões cada. Essa configuração representa um total de 72 threads.
Essa configuração na chamada do kernel é de extrema importância, pois o mau dimen-sionamento das threads e o tamanho da memória compartilhada podem afetar diretamente 1Identifica, a partir do número da versão, quais características de hardware e instruções de código são
a performance do programa. Como mencionado na Seção 3.1 desse trabalho, os blocos de threadssão divididos entre as SMs da GPU, sendo que cada CUDA core pertencente a SM fica responsável pela execução de uma thread. As threads pertencentes ao mesmo bloco têm como característica comum a possibilidade de acessar o mesmo endereço de memória chamada de memória compartilhada e poder interagir entre si através de comandos de sincronismo.
Figura 3.5: Grid de blocos e bloco de threads. Fonte: (NVIDIA CORPORATION, 2017).
Para tornar a programação mais simples, a plataforma CUDA disponibiliza algumas variáveis Built-in que auxiliam nas identificações através do ID das threads, blocos e grids, bem como as dimensões dos blocos e grid. Elas são válidas apenas para as funções executadas na GPU, e a composição delas foram uma identificação única para cada thread criada na chamada do kernel. Essas variáveis são:
• gridDim: Variável que contém as dimensões do grid. • blockIdx: Variável que contém o índice do bloco no grid. • blockDim: Variável que contém as dimensões do bloco. • threadIdx: Variável que contém o índice da thread no bloco.
3.2.3
Hierarquia de Memória
Um dos grandes devoradores de desempenho das aplicações CUDA é o uso indevido das memórias da GPU. Cada tipo de memória tem suas características, como o escopo, tempo de vida, leitura e escrita. A Tabela 2 mostra um resumo das características das principais memórias da GPU.
A principal memória da GPU é a global, ela possui alguns gigabytes, dependendo da GPU, e recebe os dados para processamento oriundos do computador. No entanto, o seu uso deve ser moderado visto que ela é a memória com o acesso mais lento em comparação com as outras memórias. Os registradores são as memórias mais rápidas para acessos não alinhados, seguidas da memória compartilhada (shared memory), textura, surface, memória local e memória global.
Quanto ao acesso, cada memória tem sua particularidade. A global é criada pelo host (aplicação na CPU), podendo ser acessada por diversos kernels e tem duração igual à da aplicação. A memória local e os registradores são criados na chamada do kernel para cada thread e possuem acesso individualizado, isso quer dizer que cada thread tem memória local e registradores únicos. A memória compartilhada também é criada na chamada do kernel, porém, para cada bloco definido na chamada, um espaço de memória compartilhada é associado e só as threads do mesmo bloco pode acessar esse espaço. Por fim, as memórias de textura e surface são criadas pelo host e tem acesso igual ao da global.
Memória Acesso Escopo Tempo de vida
Global Leitura e Escrita Grid e Blocos Aplicação Registradores Leitura e Escrita threads kernel
Local Leitura e Escrita threads kernel Compartilhada Leitura e Escrita Bloco kernel
Constante Leitura Grid e Blocos Aplicação Textura Leitura Grid e Blocos Aplicação Surface Leitura e Escrita Grid e Blocos Aplicação
Tabela 2: Tipos de memória da GPU.
3.2.4
Questões de Performance
Programar com eficiência para CUDA é um grande desafio. Todos os detalhes podem afetar o desempenho da aplicação, como o dimensionamento dos blocos, tipos de memórias usadas, padrões de acesso a memória, uso da ocupação máxima da GPU, instruções de controle de fluxo, transferência de memória entre o host e a GPU.
O dimensionamento dos blocos deve ser feito pensando no uso da capacidade máxima da GPU, o número de blocos disparados para as SMs depende diretamente da quantidade de threads por bloco, da quantidade de memória compartilhada alocada e dos registradores usados no kernel.
A utilização de forma mais eficiente das memórias da GPU geram um grande es-forço por parte do programador, devendo-se sempre buscar minimizar as transferências de memórias com baixa largura de banda2. Uma das formas de conseguir essa eficiência é
utilizar a memória compartilhada, pois ela tem uma latência bem menor que a memória global, podendo chegar a centenas de ciclos mais rápida. Outra forma é minimizar a trans-ferência de dados entre o host e a GPU, buscando sempre fazer cópias com o máximo de dados possível. Há ainda padrões de acesso coalesced (alinhados) à memória que devem ser respeitados, visto que padrões mal definidos podem gerar conflito de banco 3, como
exemplificado na Figura 3.6.
Figura 3.6: Dois tipos de acesso à memória, sendo um acesso coalesced à direita, e um acesso com bank conflicts à esquerda. Fonte: (NVIDIA CORPORATION, 2017).
Há ainda instruções de controle de fluxo que afetam significantemente a performance da aplicação, como o if e switch. Essas instruções fazem com que threads do mesmo
2Se refere a largura de banda (velocidade) da memória.
3Normalmente quando mais de uma thread tenta acessar o mesmo endereço de memória ao mesmo
warp sigam caminhos de execução diferentes. Com isso, esses caminhos são executados de forma serializada na GPU, ou seja, a execução dos comando é repetida para cada escolha diferente nesses comandos, assim, aumentando o número de instruções executadas para esse warp. Outros controles de fluxos são as instruções de sincronização de threads, que fazem com que o SM espere todas as threads do bloco finalizarem a execução até o ponto indicado.
3.3
Trabalhos Relacionados
Na literatura o método do semblance é bastante estudado devido ao seu poder inter-pretativo, existindo vários trabalho com diferentes propósitos. Por exemplo, Gong, Wang e Zhang (2016) e Luo e Hale (2012) apresentaram formas de melhorar a resolução do sem-blance, enquanto que Smith (2017) e Fomel (2009) usaram dois métodos distintos para fazer o auto picking das velocidades no semblance. O picking automático é uma tendên-cia que vem crescendo à medida que evoluímos os métodos computacionais, auxiliando principalmente em dados com grandes volumes.
O método de análise de velocidade utilizando os painéis CVS é bastante utilizado pela indústria. No entanto, devido o seu conceito ser básico não há muitos trabalhos sobre ele. As principais empresas de petróleo fazem uso desse método nos seus fluxos de processamento, buscando nele alguns benefícios, como enxergar facilmente as variações laterais de velocidade. Um dos diferenciais desse método é que ele pode ser implementado de diversas formas para o usuário final, e na medida que os hardwares avançam esse método aparece em novos formatos.
Ao analisar a literatura científica em busca de métodos geofísicos que façam uso de GPUs para otimização, é possível encontrar diversos exemplos, como o trabalho de Xu et al. (2018), que utiliza a GPU para acelerar o método De-absorption pre-stack time migration, conseguindo um speedup de quase 80×. Obregon, Salamanca e Ramirez (2017) aceleraram o processo de Reverse Time Migration utilizando um cluster de GPUs, e usando Message Passing Interface (MPI) para fazer a comunicação entre as GPUs. Uma das versões implementadas nesse trabalho faz uso de processamento em tempo de execução, e durante a busca de trabalhos relacionados não foram encontrados artigos falando sobre processamento sísmico em tempo de execução, o que traz relevância para este trabalho, fazendo com que ele abra novas metodologias de processamento de daods sísmicos.
4
Implementação
Neste capítulo são apresentados os detalhes da implementação da plataforma pro-posta, mostrando os principais módulos do programa, os algoritmos sequenciais e para-lelos desenvolvidos. As linguagens de programação utilizadas nesse projeto foram Java para a parte gráfica da aplicação, esta se resumindo à parte em que há interação do usuá-rio. Para a parte que executa o pré-processamento dos dados como a criação dos CDP Gathers, criação dos painéis CVS, e os outros dados necessários, foram utilizadas as lin-guagens C/C++ com auxílio do CUDA para o paralelismo nas GPUs e OpenMP para o paralelismo em CPU.
4.1
Apresentação da Plataforma
A plataforma tem basicamente dois módulos; o primeiro se refere as partes em que o usuário tem interação direta, sendo definido pelas telas da aplicação. A segunda parte é definida pelos programas responsáveis pela criação dos dados para a análise de velocidade. Como um dos objetivos desse trabalho é a utilização dessa aplicação para o ensino na UFRN, todos os códigos desenvolvidos nela foram escritos pelo autor, sendo alguns deles baseados nos códigos do pacote de processamento open source Seismic Unix (STOCKWELL,
1997), desenvolvido pelo Center for Wave Phenomena da Colorado School of Mines. No primeiro módulo foram criadas telas que auxiliam o usuário a gerar os dados neces-sários para a análise de velocidades. Além das telas que fazem a integração dos métodos de análise de velocidade, foram criados também programas auxiliares. Um exemplo desses programas é o que desenha o dado sísmico para o usuário, tanto na forma de wiggle como na forma de densidade variável. As Figuras 4.1, 4.2, 4.3 e 4.4 são exemplos de telas criadas para esse módulo, onde todas elas foram desenvolvidas com a linguagem Java. O principal motivo de Java ter sido escolhida como linguagem para a parte gráfica foi o conhecimento prévio e experiência nessa linguagem.
Figura 4.1: Tela inicial da aplicação. Fonte: gerada pelo autor.
Figura 4.2: Tela responsável pelo pré-processamento do dado de entrada. Fonte: gerada pelo autor.
Figura 4.3: Tela da aplicação onde é feita a análise de velocidade. Nessa tela o primeiro painel é semblance, sendo na sequência o CDP Gathers, CVP e CVS. Dado fornecido pela BP (BILLETTE; BRANDSBERG-DAHL, 2005) para uso acadêmico. Fonte: gerada pelo autor.
Figura 4.4: Tela da aplicação onde é exibida uma seção sísmica modelo, sobreposta pelo campo de velocidade interpretado até o momento. As linhas pretas representam os CDPs interpretados. Dado fornecido pela BP (BILLETTE; BRANDSBERG-DAHL, 2005) para uso
Para o segundo módulo foram separados os códigos que normalmente utilizam mais cálculos em seus processos, e portanto, precisam de mais poder computacional. Esse foi um dos motivos que nos levou a utilizar as linguagens C/C++ para esse módulo. Outro motivo levado em consideração foi que para portar os códigos para CUDA ficaria mais fácil se eles já estivessem implementados em C/C++. Para implementar um pacote de análise de velocidade são necessários vários programas, onde uns têm alto custo computacional enquanto que outros fazem apenas manuseio dos dados de entrada. Na sequência desse capítulo serão apresentados apenas os códigos sequenciais que foram portados para o CUDA juntamente com a suas versões paralelas (CUDA e OpenMP). A escolha dos códigos a serem paralelizados seguiu o critério do custo computacional, isto é, aqueles que têm o maior custo foram escolhidos. Dentre os códigos implementados apenas dois foram selecionadas, o cálculo do semblance e o cálculo do CVS. Dentre esses dois algoritmos, o segundo é o mais caro, pois calcula o NMO e faz o empilhamento para todo o dado de entrada. Já o cálculo do semblance é feito apenas em uma parte do dado de entrada.
4.2
Algoritmos Sequenciais
Os dois algoritmos que serão apresentados nessa seção foram baseados no Seimisc Unix, e utilizam a Equação 2.3 como base para para o cálculo dos tempos de trânsito e tem loops como partes principais do seu código. Dessa forma, eles são grandes candidatos a serem paralelizados. Os Algoritmos 2 e 3 dão uma ideia do funcionamento de cada um, dessa forma, podemos ver a dependência dos loops em cada um. Vale ressaltar que esses dois algoritmos foram escritos para rodarem em um único núcleo.
Quando os dois algoritmos são utilizados para processar uma grande quantidade de dados de entrada, apesar de apresentarem o resultado esperado, podem levar um tempo muito alto para conclusão, o que acaba inviabilizando de certa forma o seu uso. O grande desafio é tentar paralelizar o máximo de loops possíveis em seu código. O ideal seria transformar esses três loops do Algoritmo 3 em apenas um comando que fosse executado em paralelo. Outro ponto importante que vale ressaltar, é que esses dois algoritmos usam muitas operações de I/O na memória, e isso em alguma plataforma, como por exemplo a CUDA, pode atrapalhar a performance do programa.
Algoritmo 2 CPU - Cáculo do Semblance - Calcula o semblance para um cdp gathers.
1 // Definição do kernel
2 // ns - número de amostras;
3 // nTrcs - número de traços sísmicos de entrada 4 // nVel - número de velocidades
5 void calcSMB(float* cdpGathers, float* listOfVels, float* offsets, float ** output)
6 {
7 float ** qtde;
8 for(int i=0; i<nTrcs; i++){ 9 float offset = offsets[i]; 10 for(int v = 0; v< nVel; v++){ 11 float vel = listOfVels[v]; 12 for(int x=0; x<ns; x++){
13 float amp = calcNMO(&cdpGathers[i], vel, offset, x);
14 n[v][x] += amp; 15 d[v][x] += amp*amp; 16 qtde[v][x] += 1; 17 } 18 } 19 } 20 //suavizando 21 int suav = 3;
22 for(int v = 0; v< nVel; v++){ 23 float nsum, dsum;
24 for(int x=0; x<ns; x++){
25 for(int n=x-(suav/2); n< x+(suav/2); n++){
26 nsum += n[v][n]*n[v][n];
27 dsum += qtde[v][n]*d[v][n];
28 }
29 output[v][x] = nsum/dsun;
30 }
31 }
Algoritmo 3 CPU - Cálculo do CVS - Calcula os painéis CVS para todo o dado.
1 // Definição do kernel
2 // ns - número de amostras;
3 // nTrcs - número de traços sísmicos de entrada 4 // nVel - número de velocidades
5 void calcCVS(float* cdpsGathers, float* listOfVels, float* offsets, float *** output)
6 {
7 float *** qtde;
8 for(int i=0; i<nTrcs; i++){ 9 float offset = offsets[i]; 10 for(int v = 0; v< nVel; v++){ 11 float vel = listOfVels[v]; 12 for(int x=0; x<ns; x++){
13 float amp = calcNMO(&cdpsGathers[i], vel, offset, x);
14 output[v][cdp][x] += amp; 15 qtde[v][cdp][x] += 1; 16 } 17 } 18 } 19 //normalizar 20 for(int i=0; i < nCdps; i++){ 21 for(int v=0; v< nVel; v++){ 22 for(int x=0; x<ns; x++){
23 output[v][cdp][x] = output[v][cdp][x]/ qtde[v][cdp][x];
24 }
25 }
26 }
4.3
OpenMP (do inglês:
Open Multi-Processing)
OpenMP é uma API para programação paralela em aplicações com memória compar-tilhada, que usa diretivas de compiladores, funções e variáveis de ambiente para atingir esse paralelismo. Um exemplo de diretiva é a #pragma omp parallel for. Ela tem a função de paralelizar o for que vem logo abaixo. O programa escrito para OpenMP co-meça em uma única thread, chamada de master thread, e ao entrar na região paralela essa thread é dividida em um número de threads paralelas que vão executar ao mesmo tempo parte do código. No final dessa região paralela o programa sincroniza todas as threads e retorna para a thread principal.
Figura 4.5: Modelo de fork-join OpenMP. Fonte: (BARNEY, 2017).
A programação para OpenMP é bastante simplificada em alguns casos, bastando algumas diretrizes de compilador para tornar o código multi-thread. Esse é um dos motivos pelo qual o seu crescimento vem aumentando; o desenvolvedor não precisa fazer grandes alterações no seu código para atingir ganhos de performance.
As duas versões feitas utilizando o OpenMP dos Algoritmos 2 e 3, que serão discu-tidos na Seção 2.4 apresentaram bons resultados sendo possível notar o imediato ganho de desempenho mediante a pequenas alterações nos códigos. A grande diferença entre as versões sequenciais e OpenMP implementadas nesse trabalho foi basicamente na região do loop paralelo. Essa região será executada por mais de uma thread, ficando o seu de-sempenho dependente de quantos núcleos o processador tem disponível na momento da execução.
Algoritmo 4OpenMP - Cáculo do Semblance - Calcula o semblance para um cdp gathers.
1 // Definição do método
2 // ns - número de amostras;
3 // nTrcs - número de traços sísmicos de entrada 4 // nVel - número de velocidades
5 void calcSMB(float* cdpGathers, float* listOfVels, float* offsets, float ** output)
6 {
7 #pragma omp parallel for
8 for(int i=0; i<nTrcs; i++){ 9 float offset = offsets[i]; 10 for(int v = 0; v< nVel; v++){
11 float vel = listOfVels[v]; 12 for(int x=0; x<ns; x++){
13 float amp = calcNMO(&cdpGathers[i], vel, offset, x);
14 n[v][x] += amp; 15 d[v][x] += amp*amp; 16 qtde[v][x] += 1; 17 } 18 } 19 } 20 //suavizando 21 int suav = 3;
22 #pragma omp parallel for
23 for(int v = 0; v< nVel; v++){ 24 float nsum, dsum;
25 for(int x=0; x<ns; x++){
26 for(int n=x-(suav/2); n< x+(suav/2); n++){
27 nsum += n[v][n]*n[v][n];
28 dsum += qtde[v][n]*d[v][n];
29 }
30 output[v][x] = nsum/dsun;
31 }
32 }
Algoritmo 5OpenMP - Cáculo do Semblance - Calcula o semblance para um cdp gathers.
1 // Definição do método
2 // ns - número de amostras;
3 // nTrcs - número de traços sísmicos de entrada 4 // nVel - número de velocidades
5 // qtde - matriz denominador com a quantidade de amplitudes somadas
6 void calcCVS(float* cdpsGathers, float* listOfVels, float* offsets, float *** output)
7 {
8 #pragma omp parallel for
9 for(int i=0; i<nTrcs; i++){ 10 float offset = offsets[i];
11 for(int v = 0; v< nVel; v++){ 12 float vel = listOfVels[v];
13 for(int x=0; x<ns; x++){
14 float amp = calcNMO(&cdpsGathers[i], vel, offset, x);
15 output[v][cdp][x] += amp; 16 qtde[v][cdp][x] += 1; 17 } 18 } 19 } 20 //normalizar
21 #pragma omp parallel for
22 for(int i=0; i < nCdps; i++){ 23 for(int v=0; v< nVel; v++){ 24 for(int x=0; x<ns; x++){
25 output[v][cdp][x] = output[v][cdp][x]/ qtde[v][cdp][x];
26 } 27 } 28 } 29 30 }
4.4
CUDA
Ao iniciar os estudos desse trabalho ainda não se tinha ideia de como o código em CUDA iria funcionar. Foi necessário entender como os problemas geofísicos iriam se ade-quar à GPU. Deste modo, o algoritmo que calcula os painéis CVS foi utilizado para os estudos preliminares. Durante esses estudos foi possível constatar alguns desafios que esse algoritmo trazia para a programação em GPU, dentre eles citamos o alto número de ope-rações de I/O na memória, o grande volume de dados em alguns casos e a necessidade de usar kernels que executam uma grande quantidade de cálculos.
