RAPHAEL CHYPRIADES JUNQUEIRA AMARANTE DE EQUAÇÕES DE ONDA REPRESENTADAS EM UMA DSL ATRAVÉS DO MÉTODO DE DIFERENÇAS FINITAS

(1)

GERAC

¸ ˜

AO DE C ´

ODIGO C PARA A RESOLUC

¸ ˜

AO

DE EQUAC

¸ ˜

OES DE ONDA REPRESENTADAS

EM UMA DSL ATRAV´

ES DO M´

ETODO DE

DIFERENC

¸ AS FINITAS

S˜ao Paulo 2020

(2)

GERAC

¸ ˜

AO DE C ´

ODIGO C PARA A RESOLUC

¸ ˜

AO

DE EQUAC

¸ ˜

OES DE ONDA REPRESENTADAS

EM UMA DSL ATRAV´

ES DO M´

ETODO DE

DIFERENC

¸ AS FINITAS

Trabalho apresentado à Escola Politécnica da Universidade de São Paulo para ob-ten¸cão do T´ıtulo de Engenheiro Eletricista com ênfase em Computa¸cão.

S˜ao Paulo 2020

(3)

GERAC

¸ ˜

AO DE C ´

ODIGO C PARA A RESOLUC

¸ ˜

AO

DE EQUAC

¸ ˜

OES DE ONDA REPRESENTADAS

EM UMA DSL ATRAV´

ES DO M´

ETODO DE

DIFERENC

¸ AS FINITAS

Trabalho apresentado à Escola Politécnica da Universidade de São Paulo para ob-ten¸cão do T´ıtulo de Engenheiro Eletricista com ênfase em Computa¸cão.

Orientador:

Edson Satoshi Gomi

Co-orientador:

Hermes Senger

S˜ao Paulo 2020

(4)

Catalogação-na-publicação

Amarante, Raphael

Geração de código C para a resolução de equações de onda representadas em uma DSL através do método de diferenças finitas / R. Amarante -- São Paulo, 2020.

51 p.

Trabalho de Formatura - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais. 1.GERAÇÃO DE CÓDIGO 2.EQUAÇÕES DA ONDA 3.MÉTODO DE DIFERENÇAS FINITAS 4.PYTHON 5.C (LINGUAGEM DE PROGRAMAÇÃO) I.Universidade de São Paulo. Escola Politécnica. Departamento de

(5)

Este projeto está inserido em um contexto de imageamento s´ısmico por inversão de ondas acústicas, um problema de alto custo computacional que envolve a resolu¸cão de equa¸cões de onda. Seu objetivo central é a gera¸cão de um código C que seja o algoritmo de resolu¸cão de uma equa¸cão diferencial parcial, e que tem por base o método de diferen¸cas finitas.

Para que o problema possa ser formalizado em alto n´ıvel, a equa¸cão de onda é re-presentada em uma Domais-Specific Language que permite escrever a equa¸cão de forma simbólica, lhe conferindo simplicidade e concisão. Além disso, com essa equa¸cão se cria um estêncil que usa o método das diferen¸cas finitas para calcular os valores numéricos que a satisfazem. Em seguida, a expressão de alto n´ıvel do estêncil é traduzida em uma expressão de baixo n´ıvel, ou seja, a expressão simbólica é transformada em uma expressão de indexamento expl´ıcito que permite acessar posi¸cões de um vetor que representa o pro-blema.

Assim, as realiza¸cões deste projeto foram a cria¸cão de um analisador sintático que traduz as expressões de alto para baixo n´ıvel, e a gera¸cão de um código C que contém o algoritmo de solu¸cão para a equa¸cão diferencial parcial que descreve o problema. Tais resultados podem ser usados em projetos de imageamento s´ısmico, e o projeto em si pode ser continuado e evolu´ıdo de modo a garantir sua opera¸cão com equa¸cões mais complexas e de modo a possibilitar seu funcionamento com uma maior abrangência de problemas.

Palavras-Chave – Domain-Specific Language, equa¸cão diferencial parcial, método de diferen¸cas finitas, gera¸cão de código, inversão de onda, estêncil

(6)

This project is inserted in the context of seismic imaging by inversion of acoustic waves, a problem of high computational cost which involves solving wave equations. Its central objective is the generation of a C code that is the algorithm for solving a partial differential equation, and that is based on the finite difference method.

In order for the problem to be formalized at a high level, the wave equation is repre-sented in a Domais-Specific Language that allows the equation to be written in a symbolic way, giving it simplicity and conciseness. Further, with this equation a stencil is created that uses the finite difference method to calculate the numeric values that satisfy it. Then, the high-level expression of the stencil is translated into a low-level expression, that is, the symbolic expression is transformed into an explicit indexing expression that allows accessing positions of a vector that represents the problem.

Thus, the achievements of this project were the creation of a parser that translates expressions from high to low level, and the generation of a C code that contains the solution algorithm for the partial differential equation that describes the problem. Such results can be used in seismic imaging projects, and the project itself can be continued and evolved in order to guarantee its operation with more complex equations and in order to support a wider range of problems.

Keywords – Domain-Specific Language, partial differential equation, finite difference method, code generation, wave inversion, stencil

(7)

1 Aquisi¸cão de dados através de emissão de ondas e recep¸cão das ondas

re-fletidas . . . 11

2 Esquema do fluxo de trabalho da invers˜ao da forma de onda completa . . . 13

3 Estˆencil de cinco pontos . . . 15

4 Estˆenceis de alta ordem . . . 15

5 Pilha funcional do Devito . . . 22

6 Cronograma do planejamento do projeto . . . 26

7 Representa¸cão da condi¸cão inicial da grade de u no primeiro passo de tempo 44 8 Representa¸cão da condi¸cão final da grade de u no último passo de tempo . 45 9 Representa¸cão da condi¸cão final da grade de u gerada pelo Devito . . . 46

(8)

1 Introdu¸cão 7 1.1 Objetivo . . . 7 1.2 Motiva¸cão . . . 7 1.3 Justificativa . . . 9 1.4 Organiza¸cão do Trabalho . . . 10 2 Aspectos Conceituais 11 2.1 Imageamento por Reflexão S´ısmica . . . 11

2.2 Full-Waveform Inversion (FWI) . . . 12

2.3 Equa¸c˜oes Diferenciais Parciais e o M´etodo das Diferen¸cas Finitas . . . 13

2.4 Domain-Specific Language (DSL) . . . 16 3 Tecnologias Utilizadas 17 3.1 Linguagens de Programa¸cão . . . 17 3.2 Bibliotecas . . . 18 3.2.1 Devito . . . 18 3.2.1.1 Propósito . . . 18 3.2.1.2 Aplica¸cão . . . 19 3.2.2 Sympy . . . 22 4 Metodologia do Trabalho 25 4.1 Concep¸cão . . . 25 4.2 Planejamento . . . 26 4.3 Execu¸cão . . . 28 4.4 Fechamento . . . 28

5 Especifica¸cão de Requisitos do Sistema 30 6 Projeto e Implementa¸cão 32 6.1 Equa¸cão de Onda e DSL do Devito . . . 32

6.2 Tradu¸c˜ao da DSL com Sympy . . . 33

6.3 Gera¸c˜ao de C´odigo: Template . . . 37

(9)

8 Considera¸cões Finais 47 8.1 Conclusões do Projeto de Formatura . . . 47 8.2 Contribui¸cões . . . 49 8.3 Perspectivas de Continuidade . . . 49

(10)

1 INTRODUC

¸ ˜

AO

1.1 Objetivo

O presente trabalho está inserido no contexto do projeto STMI - Software Technolo-gies for Modeling and Inversion with Applications in Seismic Imaging, que é um projeto de pesquisa em execu¸cão no RCGI - Research Centre for Gas Innovation, na Escola Po-litécnica da USP. O contexto do projeto é investigar e criar tecnologias para simula¸cão numérica e solu¸cões para o problema da inversão s´ısmica. Essas tecnologias reduzirão o tempo necessário para desenvolver e executar código para inversão s´ısmica, um problema que, naturalmente, envolve a modelagem e simula¸cão de problemas s´ısmicos que, por sua vez, dependem integralmente da resolu¸cão de equa¸cões diferenciais parciais (EDPs) que descrevem a propaga¸cão das ondas acústicas em diferentes meios.

Dado esse contexto, o objetivo deste projeto é a gera¸cão do código que resolve tais equa¸cões de onda numericamente a partir de sua representa¸cão em uma Domain-Specific Language (DSL). Assim, o projeto segue o seguinte caminho pré-estabelecido: as equa¸cões de onda serão representadas em expressões de alto n´ıvel; tais expressões serão traduzidas para baixo n´ıvel através de algum tipo de compilador da DSL; a resolu¸cão das equa¸cões se dará pelo método das diferen¸cas finitas; e o código gerado que compõe a solu¸cão das equa¸cões será em linguagem C.

Para se atingir esse objetivo e seguir o plano de desenvolvimento, a implementa¸cão de todas essas etapas será efetuada com a linguagem de programa¸cão Python, poderosa gra¸cas ao seu alto n´ıvel de abstra¸cão e ao conjunto de pacotes cient´ıficos dispon´ıveis nessa linguagem, sendo que os mais importantes neste projeto foram o Devito e o SymPy.

1.2 Motiva¸

c˜

ao

O tema em foco neste projeto é a gera¸cão do código que resolva EDPs particulares do problema de inversão de onda, o que já vem sendo abordado e explorado por diferentes frentes.

Se por um lado temos ferramentas que nos permitem uma melhor e mais simples repre-senta¸cão simbólica de equa¸cões matemáticas, do outro temos aquelas que nos permitem uma gera¸cão de código rápida, eficiente, e as vezes até mesmo a gera¸cão de um código já otimizado. E são esses dois elementos os focos principais do projeto, merecendo uma maior elabora¸cão.

(11)

de qualquer outra linguagem dif´ıcil de ser representada diretamente em computadores, deve-se ressaltar a importˆancia de DSLs.

Domain-Specific Languages, por defini¸cão, são a formaliza¸cão de uma linguagem de programa¸cão, que representam alguma aplica¸cão espec´ıfica, como por exemplo equa¸cões matemáticas. Elas são, portanto, a ponte entre alguns problemas reais, e sua repre-senta¸cão e solu¸cão computacional.

Entretanto, como todas as demais linguagens, existem representa¸cões simbólicas mais simples e mais complexas, mais enxutas e mais extensas. As diferentes formas de se representar uma aplica¸cão espec´ıfica são, portanto, um ponto de extrema importância, e no caso espec´ıfico de equa¸cões matemáticas, ou mesmo de equa¸cões de onda, também encontramos essa multiplicidade de op¸cões e de caracter´ısticas. Aqui, as duas principais ferramentas examinadas e utilizadas em rela¸cão à representa¸cão simbólica são o SymPy e o Devito, ambas mais aprofundadas nas próximas se¸cões.

O segundo elemento fundamental do projeto é a gera¸cão de código, o que não é um assunto novo no meio cient´ıfico.

A gera¸cão de código pode ser observada em maior ou menor grau em ambientes de desenvolvimento integrado (em inglês, Integrated Development Environment - IDE), onde se gera código boilerplate ou se gera código com base em diagramas UML (Unified Mo-deling Language); em motores de templates, como por exemplo Jinja2, que permite gerar arquivos inteiros com uma lógica padrão, mas com dados espec´ıficos; ou mesmo em algu-mas linguagens de programa¸cão que permitem gera¸cão de código em tempo de execu¸cão através de fun¸cões ou classes em modo template.

O presente caso, porém, se afasta de todas essas formas de gera¸cão de código, talvez se assemelhando um pouco mais apenas com motores de templates. Isso se dá, pois de fato almeja-se uma lógica comum (o algoritmo que soluciona EDPs), e haja dados espec´ıficos (as diferentes equa¸cões de onda e os dados de cada problema), mas no problema em foco existem dois pontos de divergência.

Primeiro, quando soluciona-se EDPs numericamente, é comum se usar um estêncil, que será aprofundado mais adiante, mas que pode ser brevemente definido como um arranjo geométrico de pontos centrado no ponto que se deseja calcular. Este arranjo, por sua vez, representa aspectos do algoritmo usado para o cálculo numérico de cada ponto do problema. Tais estênceis, porém, dependem de como se representa o problema e de como se decide calcular sua solu¸cão, o que acarreta não só em uma mudan¸ca de dados caso a caso, mas efetivamente em uma mudan¸ca de lógica, fugindo dos motores de template.

O segundo ponto de divergência é o processo de gera¸cão em si, pois não se almeja inserir os dados da equa¸cão em um template fixo, mas sim traduzir a representa¸cão simbólica da

(12)

equa¸cão de onda para o código que a resolve. Esse segundo ponto também é trabalhado tanto pelo SymPy como pelo Devito, e portanto será melhor elaborado posteriormente.

Evidencia-se, então, que o foco do principal problema deste projeto e seus métodos de solu¸cão, a saber, a representa¸cão simbólica e a gera¸cão de código, estão centrados nas duas ferramentas que mais foram estudadas e usadas ao longo de seu desenvolvimento. Assim, este trabalho se insere no contexto atual de solu¸cões para os problemas descritos, além de contribuir diretamente para o corrente diálogo no grande assunto dos problemas s´ısmicos.

1.3 Justificativa

Por trás deste projeto encontra-se est´ımulos tanto na comunidade cient´ıfica quanto na indústria, pois as técnicas de modelagem e simula¸cão s´ısmica envolvem enorme custo computacional, enquanto o imageamento por reflexão de onda envolve enorme custo mo-netário.

As causas do alto custo computacional estão entrela¸cadas com conceitos técnicos que serão mais aprofundados ao longo deste documento, como equa¸cões diferenciais parciais, método das diferen¸cas finitas, e estêncil.

O que pode ser dito agora, porém, é que o código de resolu¸cão das equa¸cões de ondas acústicas contém ciclos aninhados, e, dependendo de como se representa o problema f´ısico em questão e de como se decide resolve-lo, pode-se aumentar consideravelmente tanto o número de opera¸cões quanto o número de acessos à memória realizados. Além disso, o método de inversão de onda em si envolve múltiplas itera¸cões e trabalha com um enorme volume de dados, contribuindo ainda mais para a questão do custo computacional.

Fica evidente, então, a necessidade de se otimizar o código gerado, mas isso não é algo que será especificamente tratado neste projeto. Almeja-se apenas uma gera¸cão consistente, eficiente, e simples, enquanto o aprimoramento da execu¸cão e da utiliza¸cão dos recursos computacionais serão deixados em aberto para projetos relacionados.

Contudo, deve-se adicionar que a simplicidade mencionada é crucial, dado que uma grande meta deste projeto é se tornar facilitador tanto das demais pesquisas e projetos subsequentes como, por exemplo, o aprimoramento do código gerado, quanto do diálogo entre as diferentes partes envolvidas em questões de imageamento por reflexão de onda, a saber, f´ısicos, matemáticos, geólogos, e programadores.

Já com rela¸cão às causas do alto custo monetário envolvido, estas são evidentes, pois a grande área de uso das técnicas aqui envolvidas e desenvolvidas é da prospeçcão e extra¸cão de petróleo offshore. Isso significa que a prioridade é iniciar perfura¸cões em locais onde

(13)

se sabe, e não apenas se suspeita, que valha a pena. Caso contrário, a perfura¸cão em solo oceânico, que já não é um processo simples e barato, enfrentaria perdas muito maiores e mais frequentes.

Finalmente, adiciona-se que a importância deste projeto também se deve ao simples fato de as técnicas e conceitos desenvolvidos estarem na base de problemas de enorme magnitude, evolvendo os grandes custos discutidos acima. Assim, sem uma base simples e bem feita, o resto se torna custoso e complexo em demasia.

1.4 Organiza¸

c˜

ao do Trabalho

O propósito deste documento, em sua totalidade, é cumprir com a elucida¸cão do problema e da solu¸cão do assunto tratado. Mais, ele almeja servir de referência, ponto de partida, e fonte de inspira¸cão, para projetos similares ou relacionados.

Com esses fins em mente, é necessário, em um primeiro momento, familiarizar os leitores com os conceitos, ferramentas, técnicas, e ideias envolvidos no tema em questão, e só então apresentá-los à implementa¸cão e análise desenvolvidas subsequentemente.

Para tanto, come¸caremos com uma indispensável contextualiza¸cão do projeto, abor-dando a ciência que lhe dá propósito e os desafios envolvidos que lhe dão importância. Tudo isso com o devido suporte bibliográfico.

A seguir, serão abordadas as tecnologias pertinentes ao entendimento e desenvolvi-mento do projeto, a metodologia que proporcionou seu planejadesenvolvi-mento e sua execu¸cão, e os requisitos básicos para o correto funcionamento do mesmo.

Após tratar de todos esses elementos de base e suporte, o próximo assunto será o pro-jeto em si. Serão tratadas tanto a implementa¸cão do que foi desenvolvido para solucionar o problema, como a verifica¸cão e valida¸cão do comportamento esperado.

Finalmente, o trabalho será encerrado com algumas últimas considera¸cões, versando sobre o que foi, ou deixou de ser, atingido, sobre as contribui¸cões realizadas perante o meio acadêmico-cient´ıfico, e sobre as alternativas existentes para incremento e continuidade do projeto.

(14)

2 ASPECTOS CONCEITUAIS

2.1 Imageamento por Reflex˜

ao S´ısmica

O elemento que contextualiza este projeto da forma mais abrangente é o imageamento por reflexão s´ısmica, uma prática que consiste na obten¸cão de imagens topológicas das camadas sub-superficiais terrestres através de medi¸cões de reflexos de ondas [1].

Este processo consiste na emissão de ondas acústicas ou de pressão por uma ou mais fontes. A seguir, tais ondas viajam pelos diferentes meios em questão (água, gás, sedi-mentos, rochas, etc) e são refletidas quando entram em contato com a fronteira entre dois materiais. Essa reflexão ocorre devido ao contraste de propriedades entre os materiais [1] e, mais especificamente, devido à impedância acústica, que é produto, e portanto de-pende, da velocidade de compressão da onda e da densidade do material em questão [2]. Finalmente, as ondas refletidas são captadas por um ou mais receptores.

Um grande exemplo dessa técnica são embarca¸cões offshore de prospeçcão s´ısmica ao procurarem o lugar ideal para perfura¸cão e explora¸cão de depósitos de petróleo e gás, como demonstrado na figura 1. Outros exemplos similares são de imageamento onshore ou no assoalho oceânico [3].

Figura 1: Aquisi¸cão de dados através de emissão de ondas e recep¸cão das ondas refletidas

Fonte: https://www.math.kit.edu/ianm3/seite/seismicimaging/en

Ao considerarmos os desafios técnicos, operacionais, e ferramentais desse tipo de aplica¸cão, sua importância fica evidente ao considerarmos os alt´ıssimos custos envolvidos para perfura¸cões, principalmente em solo oceânico, e o enorme desperd´ıcio de recursos

(15)

envolvido ao se come¸car uma explora¸c˜ao em solo pobre dos materiais procurados.

Assim, é inconteste a necessidade de métodos assertivos e precisos quando dessa ex-plora¸cão, resultando em uma excelente aquisi¸cão, análise, e transforma¸cão dos dados obtidos.

2.2 Full-Waveform Inversion (FWI)

Para se realizar a técnica de imageamento por reflexão s´ısmica, é preciso haver al-gum método para analisar as ondas refletidas que foram captadas pelos receptores, e é precisamente esse o papel da inversão da forma de onda completa, ou no inglês, full-waveform inversion. Mais especificamente, este é o método que permite criar imagens da sub-superf´ıcie terrestre com base nas ondas s´ısmicas refletidas, dado que elas contêm informa¸cões sobre as propriedades f´ısicas dos materiais ali encontrados [4].

Seu funcionamento baseia-se principalmente na descri¸cão de um modelo que representa o problema f´ısico, o problema real, e cujo objetivo é predizer, através de simula¸cões, as leituras dos receptores de onda dada a estrutura da sub-superf´ıcie terrestre [5]. Ou seja, com base em suposi¸cões e estimativas premeditadas dos materiais que se espera encontrar na sub-superf´ıcie, é poss´ıvel realizar uma descri¸cão matemática formal, o modelo, do campo de onda completa do problema em questão, para apenas então se proceder à inversão [4].

A primeira parte da FWI consiste na resolu¸cão das equa¸cões de onda que se usou para modelar o problema. Esta etapa, também chamada de “problema direto”, envolve discretizar o modelo em um número finito de pontos, ou seja, em uma grade de pontos (2D ou 3D), onde se deseja obter uma aproxima¸cão numérica da equa¸cão de onda [5]. Tais equa¸cões e sua discretiza¸cão serão aprofundadas na próxima seçcão.

A segunda parte da inversão, cujo nome é apropriadamente “problema inverso” se baseia não na obten¸cão dos dados calculados através do modelo, mas na obten¸cão dos dados reais captados pelos receptores. Nesta etapa, os valores captados são comparados aos calculados na primeira parte, e o erro entre ambos é registrado.

Finalmente, caso o erro seja inferior ao erro m´ınimo estipulado para o problema em questão, o processo de inversão é finalizado. Caso contrário, o valor do erro é usado para se remodelar a equa¸cão de onda na forma completa do modelo da itera¸cão anterior [4], e então o processo é repetido continuamente até que os ajustes alcancem um erro desprez´ıvel. O ciclo completo pode ser visto na figura 2.

(16)

Figura 2: Esquema do fluxo de trabalho da invers˜ao da forma de onda completa

Fonte: https://slim.gatech.edu/research/full-waveform-inversion

2.3 Equa¸

c˜

oes Diferenciais Parciais e o M´

etodo das

Diferen¸

cas Finitas

Descrita de forma generalizada, uma equa¸cão diferencial parcial (EDP) é, natural-mente, uma equa¸cão matemática que envolve derivadas parciais e que, em sua maioria, surgem de modelos f´ısicos [6].

O exemplo disso que é pertinente ao presente trabalho são as EDPs que representam a propaga¸cão de uma onda, e mais especificamente, uma onda acústica. Tais equa¸cões descrevem o comportamento da onda no tempo e no espa¸co, podendo ser escrita em sua forma bi-dimensional pela equa¸cão:

1 c2 ∗

∂2_p ∂t2 − ∇

2_{p = 0} _(2.1)

onde c representa a velocidade do som, p representa a fun¸cão da pressão acústica, depen-dente das variáveis espaciais x e y, e da variável temporal t, e o termo ∇2 _{representa o} Operador Laplaciano, que também pode ser escrito na forma:

∂2_p ∂x2 +

∂2_p

∂y2 (2.2)

Ainda, deve-se ressaltar que a fun¸cão da pressão acústica pode ser facilmente expan-dida para comportar as 3 dimensões espaciais p(x, y, z).

A descri¸cão de tais equa¸cões de onda é essencial para o problema direto da FWI, mais especificamente a modelagem do problema. Descreve-las, porém, é apenas metade da questão, sendo a outra metade referente à simula¸cão e, portanto, à resolu¸cão numérica das EDPs.

O campo de métodos numéricos oferece a solu¸cão por meio de métodos de discretiza¸cão, que nada mais significa do que obter a solu¸cão numéricas em pontos discretos do problema. Em outras palavras, opta-se por dividir o dom´ınio do problema em uma cole¸cão de pontos espa¸cados que constituem uma grade [7], e calcular o valor da equa¸cão somente em tais

(17)

pontos, em lugar de se calcular seu valor para todos os pontos que descrevem o problema em sua forma cont´ınua.

Dentre os métodos de discretiza¸cão de ondas, o mais popular é o método das diferen¸cas finitas [4], ou no inglês finite difference method (FDM).

Esse método envolve, primeiramente, criar uma grade 2D ou 3D, cujos pontos estão espa¸cados em intervalos regulares. Além disso, define-se também um intervalo regular no tempo, comumente chamado de passo de tempo. Esta etapa, como já dito, é a própria discretiza¸cão do dom´ınio do problema e deve-se garantir que a equa¸cão seja cumprida para todos esses pontos discretos.

Em seguida, temos o passo mais essencial do método das diferen¸cas finitas, que é justamente substituir as derivadas por diferen¸cas finitas [7], o que pode ser feito de acordo com diferentes aproxima¸cões.

Dentre as aproxima¸cões clássicas podemos destacar a diferen¸ca progressiva e regressiva. A t´ıtulo de exemplo, caso a discretiza¸cão ocorresse apenas no dom´ınio do tempo, isso significaria que a derivada do ponto que queremos calcular seria obtida a partir do passo seguinte no caso da diferen¸ca progressiva, e a partir do passo anterior no caso da diferen¸ca regressiva, ou seja, respectivamente:

u0(tn) ≈ un+1_{− u}n tn+1− tn , u0(tn) ≈ un_{− u}n−1 tn− tn−1 (2.3)

No caso de problemas mais complexos, como o presente, onde as derivadas são de segunda ordem no espa¸co, a aproxima¸cão costuma ser obtida através de um estêncil, que nada mais é que a expansão do método descrito anteriormente nas outras dimensões, ou seja, em lugar de usar o passo anterior ou posterior, se usa, também, os pontos espaciais vizinhos ao que se deseja calcular.

Um estêncil extremamente caracter´ıstico é o estêncil de cinco pontos, também chamado de quincôncio, ilustrado na figura 3. Este exemplo representa o cálculo de um ponto, o nó central, a partir de seus 4 vizinhos.

Ilustrando, ainda, a aplica¸cão do estêncil de forma matemática, pode-se usar o exemplo do estêncil de cinco pontos no Operador Laplaciano, cujo resultado é:

∇2_{u(x, y) ≈} u(x − h, y) + u(x + h, y) + u(x, y − h) + u(x, y + h) − 4u(x, y)

h2 (2.4)

onde h representa o espa¸camento na grade espacial.

Deve-se acrescentar que existem outros estênceis de ordens maiores, ou seja, dependem de mais pontos vizinhos e de pontos vizinhos mais distantes do nó central, o que é ilustrado

(18)

Figura 3: Estˆencil de cinco pontos

Fonte: https://www.researchgate.net/figure/Five-point-stencil fig2 228379661

na figura 4. Tais modelos de estêncil, apesar de conferirem resultados mais precisos, são fonte de grande peso computacional, podendo elevar significativamente o número de opera¸cões envolvidas. Mais uma vez, a necessidade de otimiza¸cão se mostra evidente.

Figura 4: Estˆenceis de alta ordem

Fonte: [8]

Finalmente, após ter-se escolhido o método de discretiza¸cão e substitu´ıdo as devidas derivadas, e dado que deseja-se calcular os valores da equa¸cão de onda de forma compu-tacional e automatizada, resta apenas formular o algoritmo que executa todos os cálculos necessários. Isso normalmente se dá na forma de chamadas recursivas ou de loops ani-nhados que percorrem todo o escopo do problema, resolvendo a equa¸cão numericamente

(19)

para cada ponto da grade espacial e em cada passo temporal.

2.4 Domain-Specific Language (DSL)

Uma linguagem de dom´ınio espec´ıfico, ou no inglês domain-specific language (DSL), é uma linguagem que é pensada, projetada, e propositalmente direcionada para uma aplica¸cão de um dom´ınio espec´ıfico, junto de seus aspectos mais relevantes, como seus principais conceitos e caracter´ısticas [9].

Como tal, uma DSL é arquitetada para encapsular de forma concisa e focada as nota¸cões e abstra¸cões apropriadas pertencentes a tal aplica¸cão, resultando em uma pode-rosa ferramenta de expressão [9].

Uma DSL, ent˜ao, quando feita com primor, permite trabalhar um problema espec´ıfico e complexo de forma simples, ou ao menos mais simples que sem o seu uso, ao mesmo tempo em que traz maior portabilidade, confiabilidade, otimizabilidade e testabilidade aos projetos que fazem seu uso [9].

Por fim, resta comentar que uma boa DSL advém do extenso conhecimento do dom´ınio da aplica¸cão. É esse grande conhecimento que permite estruturar a DSL de modo que seu uso seja prático e, como já dito, extremamente expressivo. E é exatamente isso que uma das principais ferramentas usadas nesse projeto faz, excluindo, assim, a necessidade de um exemplo nesta se¸cão. Essa ferramenta é o Devito, e sua merecida descri¸cão se encontra no próximo cap´ıtulo.

(20)

3 TECNOLOGIAS UTILIZADAS

3.1 Linguagens de Programa¸

c˜

ao

A linguagem de programa¸cão utilizada para o desenvolvimento e implementa¸cão do projeto é a linguagem Python.

A primeira razão para essa escolha é dada pela grande adequa¸cão dessa linguagem para altos n´ıveis de abstra¸cão. Isso permite tanto representar problemas mais complexos de uma maneira mais clara e simples, como permite aproximar o código em si da linguagem humana.

O segundo motivo para esta escolha se dá por conta do extenso ecossistema cient´ıfico proporcionado pelos módulos e bibliotecas dispon´ıveis nessa linguagem. Alguns deles serão tratados mais adiante dado que contribu´ıram plena e integralmente para a resolu¸cão do problema em questão, mas a t´ıtulo de exemplo temos: SymPy, NumPy, Pandas, Matplo-tlib, e SciPy. São esses os pacotes que permitem fazer representa¸cões simbólicas, opera¸cões matemáticas complexas, tratamentos extensos de dados, desenhos de gráficos, entre mui-tos outros processos estimados pela comunidade cient´ıfica e que permitem resolu¸cões efi-cientes de problemas.

Por último, considera-se essencial que a presente implementa¸cão possa ser interpre-tada, utilizada, modificada, e melhorada por todas as partes envolvidas no problema em questão. Então, precisamente por conta dos dois motivos anteriores, temos que a lingua-gem Python, unida à abstra¸cão e aos pacotes que proporciona, é a mais apropriada para aproximar programadores, matemáticos, geólogos, e f´ısicos. Com Python, a solu¸cão se mostra eficaz, compreens´ıvel, eficiente, e extens´ıvel. É, portanto, a melhor op¸cão.

O código gerado, por outro lado, sendo aquele que de fato aborda a resolu¸cão das EDPs, é na linguagem C. O motivo principal para essa escolha tem origem no já mencionado alt´ıssimo custo computacional envolvido no problema da inversão de onda. A linguagem C, por ser de baixo n´ıvel, e portanto mais próxima do computador, nos permite aperfei¸coar a resolu¸cão das EDPs no n´ıvel das opera¸cões executadas e dos acessos à memória. Isso, por sua vez, confere à solu¸cão apenas uma parcela da carga que seria necessária caso se utiliza-se uma linguagem de alto n´ıvel ou caso não se fizesse otimiza¸cão de execu¸cão.

Em suma, a linguagem C é um dos principais elementos que permite a indispensável otimiza¸cão computacional do problema.

(21)

3.2 Bibliotecas

Este projeto tem como principal base tecnol´ogica-computacional dois pacotes, ou bi-bliotecas, do Python: Devito e SymPy.

A primeira que será descrita a seguir, o Devito, se configura como a principal fonte de inspira¸cão e suporte computacional para este projeto, dado que ele foca, em parte, no mesmo problema de inversão de onda na forma completa e em outras questões s´ısmicas que contextualizam este trabalho.

O intuito deste trabalho é justamente usar a DSL do Devito, mas implementar uma solu¸cão diferente, ou ao menos paralela, à que ele oferece em rela¸cão à resolu¸cão de equa¸cões de onda. Isso, como será descrito adiante, foi feito através de uma engenharia reversa do Devito.

A segunda biblioteca que será descrita, o SymPy, se configura como a principal via de resolu¸cão deste projeto, dado que é justamente esse pacote que está por trás do Devito e lhe confere, assim como à esse projeto, as abstra¸cões e fun¸cões necessárias para manipular equa¸cões matemáticas, resolvê-las, e gerar código C.

3.2.1 Devito

3.2.1.1 Prop´osito

Devito é “uma DSL de diferen¸cas finitas que fornece computa¸cão de estêncil otimizada a partir de especifica¸cões de problemas de alto n´ıvel com base em expressões simbólicas de Python”[10]. Em outras palavras, o Devito é uma biblioteca do Python que fornece uma DSL espec´ıfica para se trabalhar com equa¸cões de diferen¸cas finitas. Tal DSL per-mite representar as equa¸cões de forma simbólica, e portanto permite a representa¸cão dos problemas f´ısicos e matemáticos em alto n´ıvel. Além disso, dado que tais problemas ge-ralmente envolvem alto volume de dados e alto custo computacional, o Devito fornece uma resolu¸cão por estêncil fortemente otimizada. A t´ıtulo de exemplo, o código C gerado pelo Devito apresenta uso de paralelismo e diretivas pragma, mas ainda existem outros recursos de otimiza¸cão [10].

Este projeto, porém, foca apenas na DSL do Devito, e não em seu poder de otimiza¸cão, dado que é justamente disso que se deseja desvencilhar. E a razão para isso é simples: usar a DSL para tratar de problemas matemáticos complexos de uma forma computacional mais abstrata, ou seja, em alto n´ıvel, ao mesmo tempo em que se deixa em aberto a questão da otimiza¸cão para especialistas em computa¸cão de alto desempenho (no inglês, High-Performance Computing, HPC).

(22)

da FWI, colocando a representa¸cão computacional do problema em um estado que possa ser compreendido e evolu´ıdo tanto por matemáticos, f´ısicos, e geólogos quanto por de-senvolvedores de hardware e de software. Os primeiros se adequarão facilmente à DSL de alto n´ıvel e tratarão da modelagem, enquanto os desenvolvedores se voltarão para a busca de otimiza¸cões computacionais, referentes à simula¸cão, conforme o sistema que for utilizado.

Mais especificamente, a importância de se desvincular da otimiza¸cão do Devito se dá justamente na medida do controle que se terá sobre ela. A otimiza¸cão pré-estabelecida e portanto “estática” (apesar de razoavelmente configurável e adaptável ao problema) do Devito, dará lugar a uma otimiza¸cão “dinâmica” criada por especialistas, que se adequará `

as especifica¸c˜oes do problema, do software, e do hardware utilizados.

3.2.1.2 Aplica¸c˜ao

O Devito é uma biblioteca bastante extensa, e ele ataca problemas matemáticos varia-dos através de suas inúmeras funcionalidades. Portanto, para evitar uma reprodu¸cão pro-longada e desnecessária do que pode ser encontrado em sua vasta documenta¸cão, optou-se por registrar aqui somente o necessário para o entendimento do comportamento do Devito exclusivamente relacionado ao projeto, e não de sua estrutura geral, muito menos de seus detalhes de implementa¸cão ou modo de opera¸cão.

A pe¸ca central do Devito que foi usada neste projeto e que merece maior elabora¸cão é o poder de sua DSL. É ela que permite representar uma equa¸cão diferencial de modo incrivelmente conciso, lógico e simples.

Essas caracter´ısticas são poss´ıveis gra¸cas ao SymPy, que compõe a base do Devito, permitindo-o tratar equa¸cões de forma simbólica. O que os desenvolvedores do Devito fizeram foi apenas criar abstra¸cões mais espec´ıficas e poderosas para se trabalhar com equa¸cões diferenciais mais facilmente.

Para ilustrar essa facilidade, elabora-se a seguir como criar uma fun¸c˜ao e alguns exem-plos de como manipula-la.

Primeiro, define-se uma grade que diz em quais dimensões espaciais o problema está definido, e em quantos intervalos cada dimensão se divide. E em seguida, define-se a fun¸cão atrelada à essa grade e, também, se ela é relativa ao tempo ou não:

# Grade que d i v i d e 1 metro no e i x o x e no e i x o y em 20 e s p a ¸c o s g r i d = Grid ( s h a p e =(20 , 2 0 ) , e x t e n d = ( 1 . , 1 . ) )

# Fun¸c ˜ao de nome u , no dom´ı n i o x e y ( r e f e r e n t e `a g r a d e ) , e no tempo u = TimeFunction ( name=‘u ’ , g r i d=g r i d )

(23)

A variável ‘u’ representa, então, a fun¸cão u(t, x, y) e algumas de suas manipula¸cões mais comuns são:

• u.dt : Representa a derivada parcial de u em t ∂

∂tu(t, x, y) (3.1)

• u.dxl : Representa a derivada parcial de u em x ∂

∂xu(t, x, y) (3.2)

sendo que sua discretiza¸cão se dá com o estêncil que usa o ponto atual e o ponto anterior u(x, y) hx −u(x − hx, y) hx (3.3)

• u.dxr : Representa a derivada parcial de u em x ∂

∂xu(t, x, y) (3.4)

sendo que sua discretiza¸cão se dá com o estêncil que usa o ponto atual e o ponto posterior u(x + hx, y) hx −u(x, y) hx (3.5)

• u.dy2 : Representa a derivada parcial em segundo grau de u em y

∂2

∂y2u(t, x, y) (3.6)

• u.forward : Representa a fun¸c˜ao com um passo dt no tempo

u(t + dt, x, y) (3.7)

• u.dt.evaluate : Representa o estˆencil que discretiza a derivada parcial de u em t

−u(t, x, y)

dt +

u(t + dt, x, y)

dt (3.8)

Esses exemplos deixam evidente o caráter sintético da DSL e é a combina¸cão dessas manipula¸cões que permite a constru¸cão de uma equa¸cão de modo quase literal:

eq = Eq ( u . dt2 − u . l a p l a c e ) Tal equa¸c˜ao representa:

− ∂ 2 ∂x2u(t, x, y) − ∂2 ∂y2u(t, x, y) + ∂2 ∂t2u(t, x, y) = 0 (3.9)

(24)

Agora, o que também é incrivelmente valioso é uma fun¸cão do Devito chamada “solve”. Esta fun¸cão é profundamente ligada ao SymPy, já que este possui uma fun¸cão de mesmo nome e realiza basicamente a mesma atividade. A diferen¸ca é que o Devito adaptou a fun¸cão do SymPy para trabalhar com sua própria DSL.

´

E com esta fun¸cão que é poss´ıvel criar um estêncil já rearranjado para um desejado parâmetro, ou seja, isola-se do lado esquerdo da equa¸cão o termo que se deseja obter, e do lado direito todo o resto da equa¸cão que será usado para obtê-lo.

Rearranjando a equa¸c˜ao anterior para o passo seguinte no tempo, pode-se simples-mente escrever:

s o l v e ( eq , u . f o r w a r d )

Essa fun¸c˜ao incrivelmente concisa retorna:

u(t + dt, x, y) = dt2(−2.0u(t, x, y) h2 y +u(t, x, y − hy) h2 y +u(t, x, y + hy) h2 y −2.0u(t, x, y) h2 x + u(t, x − hx, y) h2 x +u(t, x + hx, y) h2 x + 2.0u(t, x, y) dt2 − u(t − dt, x, y) dt2 ) (3.10)

Finalmente, a última parte fundamental a ser mencionada é o objeto do Devito cha-mado “Operator”. É com este objeto que é poss´ıvel transformar a expressão simbólica do estêncil em indexamento expl´ıcito, ou seja, transformar os s´ımbolos da equa¸cão em acessos à vetores, passando de, por exemplo, u(t, x, y), para u[t][x][y]. Ainda, é com a manipula¸cão deste objeto que se gera o código C já otimizado que resolve a equa¸cão.

O objetivo deste projeto, porém, é justamente obter apenas parte da funcionalidade deste objeto. Almeja-se gerar o código que resolve a equa¸cão, ao mesmo tempo em que se deixa de lado a otimiza¸cão, portanto maiores detalhes de suas funcionalidades não convêm.

Em termos práticos, aquilo do Devito que se utiliza são a sua DSL e a fun¸cão “solve”, ambos amplamente embasados no SymPy, enquanto que aquilo que se deseja reproduzir, também através do SymPy, é a tradu¸cão da expressão simbólica em indexamento expl´ıcito, e a gera¸cão de código. Este último, por sua vez, será obtido a partir de uma engenharia reversa do código gerado pelo “Operator”.

Para resumir, a figura 5 representa os cinco n´ıveis fundamentais do Devito, dentre os quais são usados os dois primeiros, almeja-se reproduzir parcialmente os próximos dois, e será deixado de lado o último.

(25)

Figura 5: Pilha funcional do Devito

Fonte: [10]

3.2.2 Sympy

A principal ferramenta que está por trás do Devito e deste projeto é o SymPy, e a razão para isso, como o próprio nome desta biblioteca sugere, é que o SymPy lida com a computa¸cão simbólica de objetos matemáticos na linguagem de programa¸cão Python. Isso significa que os objetos matemáticos são representados exatamente como intencionado e não através de uma aproxima¸cão computacional. Um exemplo que ilustra bem essa situa¸cão, e o mesmo oferecido no in´ıcio da documenta¸cão do SymPy, é o caso de ra´ızes quadradas. Quando uma raiz não é exata, ela será avaliada para uma aproxima¸cão do seu valor: a raiz de 3, por exemplo, é avaliada para 1.7320508075688772 no terminal do Python. O que o SymPy faz é permitir que a raiz de 3 seja representada pelo seu s´ımbolo, ou seja, sqrt(3) no Python, que equivale a √3. Além disso, e talvez mais interessante, o SymPy permite que variáveis não inicializadas sejam mantidas em sua forma simbólica, ou seja, se escrevermos algo como a + b + c o SymPy representará essa expressão exatamente como ela está, enquanto o Python retornaria um erro, já que não temos os valores de a, b ou c.

Novamente, não compete a este documento reproduzir o que já pode ser encontrado minuciosamente descrito e exemplificado na documenta¸cão desta biblioteca. Porém, aquilo que foi indispensável para a execu¸cão do projeto merece algumas considera¸cões à respeito de seu funcionamento. Essas funcionalidades essenciais estão divididas em 3 grandes módulos do SymPy: “core”, “codegen”, e “printing”.

(26)

O módulo “core” é, obviamente, o núcleo do SymPy. É com ele que se torna poss´ıvel trabalhar com expressões simbólicas, sendo que seus elementos mais utilizados ao longo do projeto foram justamente “Symbol” e “Eq”.

“Symbol” é o que permite definir uma variável não inicializada como um s´ımbolo, de modo que seja poss´ıvel usa-lo em sua forma simbólica em uma expressão, e não em sua forma avaliada. É poss´ıvel criar um s´ımbolo da seguinte forma:

a = Symbol ( ‘ a ’ )

J´a “Eq”, abrevia¸c˜ao de “Equality”, representa uma igualdade que possibilita repre-sentar algo como c2 _{= a}2_{+ b}2 _{(dado que os s´ımbolos a, b, e c j´}_{a foram criados) da seguinte} forma:

eq = Eq ( c ∗ ∗ 2 , a ∗∗2 + b ∗ ∗ 2 )

O segundo módulo mais utilizado, “codegen”, é o módulo que, naturalmente, possibi-lita trabalhar com a gera¸cão de código em inúmeras linguagens de programa¸cão.

Aquilo que ele oferece que é de maior interesse para o projeto é sua abordagem para com a árvore sintática abstrata, ou no inglês, Abstract Syntax Tree (AST), através da qual o SymPy reconhece e organiza os elementos do código a ser gerado.

A AST é uma estrutura de dados em forma de árvore que representa a sintaxe de um código escrito com uma linguagem de programa¸cão. Através dela é poss´ıvel distinguir e analisar os diferentes elementos sintáticos que compõe o código, tal como declara¸cões, tipos de elementos, strings, vetores, ciclos “for”, ciclos “while”, chamadas de fun¸cões, etc. Para ilustrar de alguma forma estes conceitos, serão descritos mais a fundo aqueles elementos sintáticos do SymPy mais utilizados na implementa¸cão do projeto.

• Assignment: representa a atribui¸cão de um valor para alguma variável. Por exemplo, o código

x = x + 1 ;

pode ser representado por

a s s i g n m e n t = Assignment ( x , x + 1 )

• Declaration: representa a declara¸cão de uma variável. Por exemplo, o código i n t x ;

d e c l a r a t i o n = D e c l a r a t i o n ( ’ x ’ )

(27)

• Element: representa um elemento de um vetor. Por exemplo, o peda¸co de c´odigo para acesso de um vetor por indexamento

v [ i ] [ j ] [ k ]

e l e m e n t = Element ( ‘ v ’ , ‘ i j k ’ )

• For: representa um ciclo “for”, contendo sua inicializa¸cão, condi¸cões, e corpo. Por exemplo, o código

f o r ( i = 0 , i < 1 0 , i +=1) { x = x + 1 ;

}

f o r i = For ( i , Range ( 1 0 ) , [ Assignment ( x , x + 1 ) ] )

• FunctionPrototype: representa a assinatura de uma fun¸cão, contendo seu nome, o tipo de seu retorno, e seus parâmetros. Por exemplo, o código

double f u n c t i o n ( double a , double b )

p r o t o t y p e = F u n c t i o n P r o t o t y p e ( r e a l , ’ f u n c t i o n ’ , [ a , b ] )

Finalmente, o terceiro e último módulo de suma importância, “printing”, é aquele que traduz as expressões simbólicas descritas com o SymPy, seja usando o módulo “core”, seja usando “codegen”, ou até uma combina¸cão de ambos, na expressão correspondente `

a linguagem de programa¸cão desejada. O SymPy possibilita traduzir as expressões em inúmeras linguagens, como Java, Fortran, Latex, Rust, entre muitas outras, dentre as quais aquela que foi usada no projeto é a linguagem C.

Para se obter a expressão correspondente na linguagem C, utiliza-se o método “ccode”. E seu uso já foi demonstrado nos exemplos dos elementos da AST acima, dado que se as chamadas “ccode(assignment)”, “ccode(declaration)”, “ccode(for i)”, ou “ccode(elem)” forem feitas, elas retornarão precisamente o código que foi dado em cada exemplo.

Ainda, é importante ressaltar que outras funcionalidades do SymPy foram usadas e experimentadas ao longo do projeto, mas o que foi aqui apresentado representa fielmente o centro de interesse e de aplica¸cão para a solu¸cão do problema proposto.

(28)

4 METODOLOGIA DO TRABALHO

4.1 Concep¸

c˜

ao

Reiterando e resumindo o que foi elaborado nas se¸cões anteriores, a necessidade deste projeto provém, mais genericamente, da necessidade de se trabalhar computacional e programaticamente com problemas matemáticos e f´ısicos que podem envolver alto custo computacional e, por vezes, alto custo monetário. Mais especificamente, é necessário viabilizar os meios de se resolver equa¸cões diferenciais parciais para que isso possa ser usado em ferramentas de inversão de onda na forma completa. Além disso, isso deve ser feito de uma maneira que seja compreens´ıvel para as diferentes partes que integram problemas s´ısmicos.

Portanto, define-se a questão e meta centrais deste projeto como sendo a imple-menta¸cão de uma ferramenta que resolva equa¸cões diferenciais parciais, ao mesmo tempo em que se preza pela simplicidade, compreensibilidade, e facilidade tanto de uso como de evolu¸cão. Já a viabilidade de se alcan¸car essa meta se dá na medida em que este projeto se inspira e se baseia em outras solu¸cões para problemas similares, e devido às excelentes ferramentas existentes que servem de suporte ao presente trabalho.

Além disso, essas solu¸cões e ferramentas, principalmente o Devito e o SymPy, são os recursos fundamentais que garantem que as caracter´ısticas almejadas (simplicidade, compreensibilidade, etc) sejam acatadas. Porém, ainda é necessário ressaltar que sem as facilidades da linguagem Python e seu grande ecossistema cient´ıfico, isso se tornaria bem mais dif´ıcil. Ainda, devido ao contexto do projeto destacar o alto custo computacional dos problemas envolvidos, faz-se também necessário a velocidade da solu¸cão em resolver as equa¸cões, e a possibilidade de otimizar tal solu¸cão para problemas ou elementos de hardware espec´ıficos. Aqui, então, é que se faz necessário a presen¸ca de uma linguagem de baixo n´ıvel, como a linguagem C, para atacar essas exigências.

Define-se, então, a proposta do projeto como sendo implementar um programa em linguagem Python que gere um código C, esse sim, que resolva as equa¸cões diferenciais parciais. Mais, isso será feito com a engenharia reversa do Devito, e com total suporte do SymPy. Assim, todas as metas se tornam fact´ıveis e o projeto pode ser implementado com a garantia de alcan¸car um estado funcional e válido.

(29)

4.2 Planejamento

O planejamento do projeto consiste de três partes distintas, como pode ser visto na fi-gura 6. Suas subdivisões representam os pontos mais importantes de todo o percurso deste projeto, e o intervalo de tempo que lhes foi destinado foi seguido sem muitas distor¸cões.

Figura 6: Cronograma do planejamento do projeto

A primeira, “Atividades Prim´arias”, diz respeito ao di´alogo inicial entre as partes envolvidas, o aluno e os orientadores. Foi nessa etapa onde se delimitou o escopo do projeto, se definiu suas metas, e se elucidou seu motivo de vir a ser.

O essencial a destacar nessa etapa são os estudos preliminares e a familiariza¸cão com as ferramentas. Ambos foram cardinais para o correto entendimento do que se desejava e de como isso seria alcan¸cado. Os estudos se voltaram mais para como se trabalhar com a resolu¸cão de equa¸cões através do Python, enquanto as ferramentas que necessitavam de familiariza¸cão foram, sem surpresa, o Devito e o SymPy.

Essa familiariza¸cão foi necessária pois ambas as bibliotecas são extensas e porque seu funcionamento e como utiliza-las de modo vantajoso em dado contexto não são necessa-riamente aparentes de imediato. Além disso, havia bastante material de referência, como a documenta¸cão do código, v´ıdeos de palestras dos responsáveis por cada ferramenta, e artigos cient´ıficos, dentre os quais os mais úteis são mencionados na bibliografia.

A segunda parte, “Atividades do Projeto”, envolve as etapas mais óbvias de um tra-balho de conclusão de curso direcionado à engenharia de computa¸cão, com a aloca¸cão de um tempo aproximadamente igual entre revisão bibliográfica, implementa¸cão do código, e reda¸cão da monografia. Ainda, foi alocado um tempo extra dedicado à valida¸cão do que foi desenvolvido.

(30)

Essa divisão, contudo, é um tanto quanto simplificada no que diz respeito à imple-menta¸cão e, portanto, cabe aqui uma enumera¸cão de suas principais submetas.

Os grandes passos representativos de real progresso no trabalho s˜ao:

1. Representar uma equa¸cão de onda usando o Devito. A complexidade do problema pode variar desde uma simples equa¸cão de onda, até um elaborado modelo s´ısmico. A representa¸cão ao final do projeto seria escolhida de acordo com o tempo dispon´ıvel para sua correta implementa¸cão.

2. Traduzir a representa¸cão da equa¸cão de onda usando o SymPy, de modo que ao invés de se ter uma representa¸cão simbólica, tenha-se uma estrutura de dados. Em outras palavras, traduzir a expressão em alto n´ıvel (ex.: u(t, x, y)), em uma expressão de baixo n´ıvel com indexamento expl´ıcito (ex.: u[t][x][y]).

3. Gerar um arquivo C correspondente à resolu¸cão da equa¸cão de onda com um m´ınimo de código gerado e um máximo de código já em um template definido. Esse passo de transi¸cão é necessário para verificar se a tradu¸cão da etapa anterior é funcional e compilável, sendo justamente essa tradu¸cão o código gerado.

4. Gerar um arquivo C correspondente à resolu¸cão da equa¸cão de onda com um máximo de código gerado e um m´ınimo de código já em um template definido. Essa é a forma última do que se deseja alcan¸car, onde quase todo o código é gerado através do SymPy especificamente para cada caso, e o template não passa de um pequeno header ou o m´ınimo necessário.

Os detalhes da implementa¸cão de cada um desses passos, junto de se foi poss´ıvel total ou apenas parcialmente alcan¸cá-los será descrito na se¸cão apropriada.

Finalmente, resta salientar que o maior ou menor grau de complexidade que se conse-guiu alcan¸car em cada passo tem rela¸cão direta com o tempo dispon´ıvel para a realiza¸cão do projeto. Esse maior ou menor grau, contudo, não representa real inconveniência para o propósito do projeto, dado que ele será integrado à um projeto maior que poderá lhe dar continuidade gra¸cas ao presente documento e à aten¸cão à extensibilidade que foi dada na implementa¸cão do código.

A última parte, “Atividades Acadêmicas”, faz referência apenas ao acompanhamento e avalia¸cão do projeto por parte da universidade. Esta parte não necessita maior elabora¸cão.

(31)

4.3 Execu¸

c˜

ao

Esta subse¸cão se volta não para o que foi executado, mas sim para a abordagem com que se resolveu executar as tarefas descritas no planejamento, primeiro tratando de todas as tarefas anteriores à implementa¸cão e, depois, da implementa¸cão em si.

Com rela¸cão às atividades preliminares já foi mencionado o material utilizado, mas em se tratando do método utilizado, aquele que foi mais rápido para a compreensão das ferramentas foi seguir e fazer pequenos experimentos com seus tutoriais dispon´ıveis em formato Jupyter Notebook, uma aplica¸cão web que suporta documenta¸cão com “live code”, ou seja, código que pode ser executado e experimentado ao longo do documento. Isso, somado com os v´ıdeos de palestra achados online, foram essenciais para dar in´ıcio à estrutura¸cão de como as ferramentas seriam utilizadas na fase de implementa¸cão.

A segunda atividade que antecedeu a implementa¸cão foi a pesquisa bibliográfica, e ela foi extremamente valiosa para situar o problema nos diferentes n´ıveis de contextualiza¸cão que ele necessita. Sem compreender os conceitos de imageamento por reflexão s´ısmica, FWI, equa¸cões diferenciais parciais, e DSLs, seria mais dif´ıcil realizar um projeto com esse grau de complexidade e no curto intervalo de tempo dispon´ıvel para fazê-lo, pois não seria poss´ıvel distinguir categoricamente o que deve ser priorizado do que não deve. Em outras palavras, essa foi a abordagem utilizada para se executar o projeto; foi priorizado o absolutamente necessário para se atingir resultados válidos e uma ferramenta que pode facilmente integrar o grande projeto em que este está inserido.

Finalmente, com rela¸cão à implementa¸cão em si, e dado o foco em prioriza¸cão menci-onado, o protocolo sempre foi atingir um dos passos mencionados no planejamento antes de mudar para o próximo. Além disso, cada passo foi atingido primeiro com o caso mais simples, para somente então, e apenas com disponibilidade de tempo, partir para um caso mais complexo ou uma forma mais genérica de implementa¸cão, expandindo o alcance da aplica¸cão.

Ao fim, foi poss´ıvel garantir uma implementa¸cão de cada passo mais, ou menos, com-plexo e/ou genérico, como será discutido mais adiante.

4.4 Fechamento

Por último, deve-se falar da abordagem escolhida em rela¸cão ao fechamento do projeto, ou seja, em rela¸cão à valida¸cão, à avalia¸cão, e à evolu¸cão deste trabalho.

Já que este projeto foi concebido, planejado, e executado, tendo por base a engenharia reversa do Devito, não há nada mais lógico do que validá-lo com compara¸cões diretas aos resultados obtidos no Devito. É necessário lembrar, porém, que este projeto almeja

(32)

alcan¸car a mesma, ou similar, funcionalidade que o Devito, e não sua performance, já que isso ficará a cargo de especialistas em otimiza¸cão. Portanto o que se espera são resultados compat´ıveis, e não um código C mais avan¸cado e mais rápido.

A avalia¸cão do que foi ou não foi alcan¸cado, ou se foi parcial ou totalmente alcan¸cado, ficará a cargo das considera¸cões finais deste documento. Porém, como já mencionado, qualquer falta que não compromete o funcionamento do código não prejudica a proposta ulterior deste trabalho, que é ser integrado em outro projeto, dado que ele poderá ser facilmente continuado por vias deste documento e da apresenta¸cão do código em si. Assim, a evolu¸cão das ideias e utilidades aqui desenvolvidos poderá ser executada.

Finalmente, resta real¸car que este documento é pe¸ca essencial do fechamento do pro-jeto, dado que ele reúne, na forma mais didática poss´ıvel, os conhecimentos sobre todos os n´ıveis de contextualiza¸cão, sobre todo o ferramental utilizado, e sobre a solu¸cão imple-mentada do problema multidisciplinar que foi tema deste projeto.

(33)

5 ESPECIFICAC

¸ ˜

AO DE REQUISITOS DO

SISTEMA

Este projeto foi desenvolvido com a linguagem de programa¸cão Python e ele se destina a integrar outros projetos em Python que tratam de imageamento s´ısmico. Com isso em mente, é desejado que o presente projeto possa ser usado e evolu´ıdo sem impedimentos por conta de qualquer dependência ou requisito de sistema, todos detalhados a seguir.

Como dito, o programa foi implementado em Python, mais especificamente a versão 3.8.3 e, portanto, para executá-lo é necessário possuir algum interpretador do Python atual o suficiente. Assim, recomenda-se usar as últimas versões dispon´ıveis do Python 3.6, 3.7, ou 3.8. Não é garantido que versões mais antigas funcionem corretamente, e de modo algum se recomenda Python 2, recentemente descontinuado.

Com rela¸cão às dependências, o programa faz uso de quatro bibliotecas que devem ser instaladas antes de se executar o programa. Todas essas dependências estão em um arquivo no programa chamado requirements.txt, e recomenda-se que sua instala¸cão seja feita através do gerenciamento de pacotes do Python, pip, o que pode ser feito com o comando: pip install -r requirements.txt. Existem, porém, comandos similares em outros gerenciadores de pacotes como Anaconda.

Ainda com rela¸cão às dependências, cabe aqui uma breve descri¸cão de cada uma:

• Devito: já descrito anteriormente e indispensável para a realiza¸cão do projeto, a instala¸cão do Devito segue as recomenda¸cões de sua própria documenta¸cão. E´ recomendado instalar o Devito pelo pip, chamando seu repositório Git, ou seja, “git+https://github.com/devitocodes/devito.git” (já presente no arquivo de reque-rimentos);

• SymPy: já descrito anteriormente e também essencial para a implementa¸cão do projeto;

• NumPy: biblioteca de opera¸cões matemáticas, vetoriais, e matriciais incrivelmente poderosa. Usada rapidamente apenas para passar, eficientemente, alguns dados do problema para o template que gera o código C;

• Jinja2: essa biblioteca é um motor de templates, ou seja, permite passar valores do código Python para um template pré-estabelecido em qualquer linguagem de programa¸cão, no caso, C. Essa ferramenta trata da descri¸cão de um template que contém elementos estáticos, como um header e uma fun¸cão main, enquanto que os demais elementos do problema, os elementos dinâmicos que mudam caso a caso,

(34)

são exportados direto do programa em Python, como o algoritmo de resolu¸cão de ondas, seus parâmetros, e os dados do problema.

Novamente, como o intuito deste projeto é ser usado e continuado em projetos de maior escala, a simplicidade de seus requisitos de funcionamento é intencional. Assim, apenas um interpretador recente e uma instala¸cão feita através de um único comando já são suficientes para executar o programa. E com rela¸cão ao baixo volume de dependências, os problemas aqui tratados já foram e ainda são abordados por poderosas ferramentas do enorme ecossistema cient´ıfico na linguagem Python. Assim, fez-se uso apenas do indispensável.

Finalmente, com rela¸cão aos requisitos do código C gerado, é necessário apenas um compilador. Recomenda-se o conhecido gcc (GNU Compiler Collection). Além disso, o código gerado deve ser compilado com a flag −lm, que procura e liga a biblioteca libm, dado que no header do código C gerado é feita uma referência à biblioteca “math.h”. Fora isso, o código foi feito para funcionar corretamente por si só.

(35)

6 PROJETO E IMPLEMENTAC

¸ ˜

AO

Esta se¸cão é dedicada a uma elabora¸cão detalhada da forma como foram implemen-tados os grandes passos definidos no planejamento.

Almeja-se descrever como o tópico principal de cada passo foi atingido, de forma que todos eles possam ser não apenas compreendidos, mas também que eles possam ser facilmente continuados, aumentando-se a complexidade da ferramenta e a abrangência de sua aplica¸cão em problemas ligados ao imageamento s´ısmico.

6.1 Equa¸

c˜

ao de Onda e DSL do Devito

Como antecipado no planejamento, a complexidade do problema trabalhado depen-deria do tempo dispon´ıvel para sua conclus˜ao e do progresso de seu desenvolvimento ao longo do tempo alocado.

O cenário que certamente mais beneficiaria o grande projeto que engloba este, seria o caso onde o problema s´ısmico já poderia ser descrito por completo, isto é, onde se pudesse formalizar um modelo matemático que inclu´ısse as fontes das ondas sonoras, os receptores, uma geometria mais elaborada, e condi¸cões de borda bem definidas. Contudo, chegou-se a conclusão que isso seria complexo demais para se desenvolver no curto prazo dispon´ıvel. Optou-se, portanto, por ater-se ao tema que intitula este documento e trabalhar apenas com equa¸cões de onda, e não modelos completos.

Assim, adotou-se a equa¸c˜ao de onda em sua forma bi-dimensional mais gen´erica:

1 c2 ∗

∂2_p ∂t2 − ∇

2_{p = 0} _(6.1)

Com a equa¸cão de onda estabelecida, o próximo passo seria traduzi-la para a DSL do Devito, o que, como demostrado anteriormente, não traz grandes dificuldades dado o grande poder sintético do Devito.

Para formar a equa¸cão de onda basta definir uma grade e uma fun¸cão temporal, ambas levando em conta as dimensões x e y. A t´ıtulo de exemplo temos:

g r i d = Grid ( s h a p e =(21 , 2 1 ) , e x t e n t = ( 1 . , 1 . ) )

u = TimeFunction ( name= ’ u ’ , g r i d=g r i d , s p a c e o r d e r =2 , t i m e o r d e r =2)

Aqui, um espa¸co de um metro no eixo x e um metro no y foram divididos em 21 partes, e a fun¸c˜ao criada representa u(t, x, y).

´

E poss´ıvel, então, criar a equa¸cão diferencial parcial da onda usando a segunda derivada no tempo e o operador laplaciano, ambos fornecidos em forma simbólica pelo Devito.

(36)

Ainda, é necessário criar uma variável para a velocidade c que, aqui, será dada como 1 por fins de simplicidade aritmética. Assim, temos:

pde = ( 1 / c ∗ c ) ∗ u . dt2 − u . l a p l a c e

Finalmente, para concluir esta primeira etapa e dar abertura à próxima, é preciso transformar a equa¸cão diferencial parcial em um estêncil, em uma equa¸cão que representa o novo estado da fun¸cão no próximo intervalo de tempo.

Para isso devemos criar uma equa¸cão onde seu lado esquerdo representa o novo estado na dimensão do tempo, e seu lado direito representa o rearranjo da equa¸cão diferencial parcial em respeito à esse novo estado. Isso seria, para o exemplo dado acima, respecti-vamente:

u(t + dt, x, y) (6.2)

1.0 ∗ dt2∗ (−2.0 ∗ u(t, x, y) + u(t, x, y − hy) + u(t, x, y + hy) h2

y

+−2.0 ∗ u(t, x, y) + u(t, x − hx, y) + u(t, x + hx, y) h2

x

+2.0 ∗ u(t, x, y) − 1.0 ∗ u(t − dt, x, y)

dt2 )

(6.3)

Novamente, com uso do Devito, ´e poss´ıvel escrever tal equa¸c˜ao de forma muito mais sucinta e compreens´ıvel, de modo que ao final desta primeira etapa, temos:

s t e n c i l = Eq ( u . f o r w a r d , s o l v e ( pde , u . f o r w a r d ) )

6.2 Tradu¸

c˜

ao da DSL com Sympy

Nesta etapa, almeja-se traduzir a representa¸cão simbólica do estêncil obtido na etapa anterior em uma expressão com indexamento expl´ıcito. Pode-se dizer, então, que deseja-se reproduzir parte do comportamento do objeto “Operator” do Devito, fazendo uso do SymPy.

Para executar essa tarefa, implementou-se uma classe chamada “Parser”, ou seja, um analisador sintático, que lê a representa¸cão em alto n´ıvel da equa¸cão e gera a representa¸cão correspondente em baixo n´ıvel.

Nesta tradu¸cão, as duas ferramentas indispensáveis são o próprio SymPy, já introdu-zido neste documento, e o Regex, ou expressões regulares.

Esta ferramenta, dispon´ıvel em inúmeras linguagens de programa¸cão e até em busca-dores de palavras em editores de texto, permite que quaisquer sequências de caracteres

(37)

desejadas sejam identificadas em uma outra sequência de caracteres, normalmente uma frase, um parágrafo, ou um texto inteiro. Essa ferramenta permite, por exemplo, identi-ficar todos os números em um texto, ou todas as palavras que come¸cam por certa letra, ou até mesmo por¸cões inteiras que incluem determinado padrão de caracteres.

Descrever minuciosamente como essa ferramenta funciona não convém aos objetivos deste documento. Porém os padrões de identifica¸cão usados no analisador sintático serão devidamente descritos, assim como o motivo de seu uso.

A primeira coisa que o Parser faz é transformar o estêncil em uma string, ou seja, uma cadeia de caracteres. No exemplo anterior, obtém-se:

Eq ( u ( t + dt , x , y ) , 1 . 0 ∗ dt ∗∗2∗( −2.0∗ u ( t , x , y ) / h y ∗∗2 + u ( t , x , y − h y ) / h y ∗∗2 + u ( t , x , y + h y ) / h y ∗∗2 − 2 . 0 ∗ u ( t , x , y ) / h x ∗∗2 + u ( t , x − h x , y ) / h x ∗∗2 + u ( t , x + h x , y ) / h x ∗∗2 + 2 . 0 ∗ u ( t , x , y ) / dt ∗∗2 − 1 . 0 ∗ u ( t − dt , x , y ) / dt ∗ ∗ 2 ) )

Em seguida, deve-se identificar os s´ımbolos livres do estêncil, isto é, aqueles s´ımbolos que deveriam, mas ainda não estão, atrelados a uma variável espec´ıfica que represente este s´ımbolo. No presente caso, os s´ımbolos livres são: ‘h y’, ‘x’, ‘y’, ‘dt’, ‘t’ e ‘h x’. O s´ımbolo ‘u’ não é uma variável livre, pois ele já está vinculado a uma variável. A lista de s´ımbolos é facilmente obtida com uma fun¸cão do Devito originária de uma fun¸cão de mesmo nome do SymPy.

Dado esse preparo, é poss´ıvel atacar de fato a tradu¸cão da expressão do Devito em uma expressão de indexamento expl´ıcito. E isso se faz, antes, com a tradu¸cão do Devito em uma expressão puramente SymPy, sem as abrevia¸cões sintáticas que o Devito proporciona. A razão de se realizar esta opera¸cão, ao invés de realizar uma tradu¸cão direta, é que o SymPy, como já descrito, possui uma fun¸cão que transforma a expressão simbólica diretamente em código C. Em outras palavras, assim que se obtiver a expressão em alto n´ıvel em formato SymPy, é poss´ıvel gerar a expressão de baixo n´ıvel com uma única chamada da fun¸cão ‘ccode’.

A tradu¸c˜ao Devito-SymPy possui 3 partes:

1. Substituir as fun¸c˜oes

2. Substituir os s´ımbolos livres

3. Substituir os n´umeros decimais, ou floats

A primeira substitui¸cão utiliza o padrão Regex u\((.*?)\). Isso quer dizer que ele identificará todas as fun¸cões u(...), não importa seu conteúdo. Além disso, cada fun¸cão

(38)

identificada será substitu´ıda pela string do seu equivalente SymPy, o objeto Element descrito anteriormente. Essa transforma¸cão é necessária, pois a fun¸cão ‘ccode’ não suporta o atual estado do estêncil.

Deve-se adicionar que nesta substitui¸cão é realizada a solu¸cão de um problema que, se não feita aqui, exigiria mais processamento póstumo.

Do jeito que o Regex está formulado, busca-se a fun¸cão completa, mas na hora da substitui¸cão pode-se facilmente trabalhar ou com a fun¸cão como um todo, ou com seus parâmetros. Isso é necessário para se declarar o elemento como “Element(’u’, parame-ters.split(’, ’)), o que nos devolve, por exemplo, “Element(u, indices=(t, h x + x, y))”.

Acontece que os termos ‘h x’, ‘h y’, e ‘dt’, enquanto ´ındices da fun¸cão, fazem parte da equa¸cão apenas em sua expressão de alto n´ıvel. Por outro lado, durante o indexamento expl´ıcito, deseja-se poder acessar as posi¸cões de um vetor multidimensional uma a uma.

Quando a fun¸cão foi criada com base em uma grade, já se deixou impl´ıcito que cada ponto no espa¸co seria separado por uma distância de h x e h y em cada eixo. Portanto, ao se transformar a equa¸cão em um vetor multidimensional, um incremento de uma unidade no ´ındice de cada dimensão representaria exatamente esse passo, representado por esses s´ımbolos. Em outras palavras, em vez de se usar u[t][x + h x][y], por exemplo, usa-se u[t][x + 1][y].

Assim, todos os s´ımbolos que representam um passo em alguma dimensão devem ser transformados no número 1. Para o exemplo, obtém-se:

Eq ( Element ( u , i n d i c e s =( t + 1 , x , y ) ) , 1 . 0 ∗ dt ∗ ∗ 2 ∗ ( −2.0∗ Element ( u , i n d i c e s =(t , x , y ) ) / h y ∗∗2 + Element ( u , i n d i c e s =(t , x , y − 1 ) ) / h y ∗∗2 + Element ( u , i n d i c e s =(t , x , y + 1 ) ) / h y ∗∗2 − 2 . 0 ∗ Element ( u , i n d i c e s =(t , x , y ) ) / h x ∗∗2 + Element ( u , i n d i c e s =(t , x − 1 , y ) ) / h x ∗∗2 + Element ( u , i n d i c e s =(t , x + 1 , y ) ) / h x ∗∗2 + 2 . 0 ∗ Element ( u , i n d i c e s =(t , x , y ) ) / dt ∗∗2 − 1 . 0 ∗ Element ( u , i n d i c e s =( t − 1 , x , y ) ) / dt ∗ ∗ 2 ) )

A segunda substitui¸cão utiliza o padrão Regex “\w+”. Isso quer dizer que ele identi-ficará todas as palavras compostas somente pelas letras do alfabeto. Aqui é que entram os s´ımbolos livres identificados anteriormente, pois verifica-se se cada palavra está entre os s´ımbolos e, em caso positivo, a palavra identificada será substitu´ıda pela string do seu equivalente SymPy, o objeto Symbol descrito anteriormente.

(39)

quaisquer variáveis, nâo se pode avaliar a string em uma expressão que possa ser convertida em código C pela fun¸cão “ccode”.

Ao fim desta opera¸c˜ao, obt´em-se:

Eq (

Element ( u , i n d i c e s =(Symbol ( ’ t ’ ) + 1 , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) ) ) , 1 . 0 ∗ Symbol ( ’ dt ’ ) ∗ ∗ 2 ∗ (

−2.0∗ Element ( u , i n d i c e s=

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) ) ) / Symbol ( ’ h y ’ ) ∗ ∗ 2

+ Element ( u , i n d i c e s=

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) − 1 ) ) / Symbol ( ’ h y ’ ) ∗ ∗ 2

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) + 1 ) ) / Symbol ( ’ h y ’ ) ∗ ∗ 2

− 2 . 0 ∗ Element ( u , i n d i c e s=

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) ) ) / Symbol ( ’ h x ’ ) ∗ ∗ 2

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) − 1 , Symbol ( ’ y ’ ) ) / Symbol ( ’ h x ’ ) ∗ ∗ 2

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) + 1 , Symbol ( ’ y ’ ) ) ) / Symbol ( ’ h x ’ ) ∗ ∗ 2

+ 2 . 0 ∗ Element ( u , i n d i c e s=

( Symbol ( ’ t ’ ) , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) ) ) / Symbol ( ’ dt ’ ) ∗ ∗ 2

− 1 . 0 ∗ Element ( u , i n d i c e s=

( Symbol ( ’ t ’ ) − 1 , Symbol ( ’ x ’ ) , Symbol ( ’ y ’ ) ) / Symbol ( ’ dt ’ ) ∗ ∗ 2 ) )

A terceira, e última, substitui¸cão utiliza o padrão Regex “\d+\.\d+”. Isso que dizer que ele identificará todos os números decimais, ou seja, aqueles separados por um ponto. Além disso, cada número identificado será substitu´ıdo pela string do seu equivalente SymPy, o objeto Float, que representa, naturalmente, o tipo “float” de números decimais. Esta última substitui¸cão pode parecer supérflua, porém sem ela o código não funciona