Gera¸c˜ ao de C´ odigo Final - RAPHAEL CHYPRIADES JUNQUEIRA AMARANTE DE EQUAÇÕES DE ONDA REPRES

Nesta última etapa, almeja-se gerar o máximo de código poss´ıvel fazendo uso do SymPy e de suas funcionalidades de gera¸cão de código C. Dessa maneira, é poss´ıvel se desvencilhar do código gerado pelo Devito, fazendo uso de um template cujo código principal, ou seja, o algoritmo de resolu¸cão, possa ser gerado totalmente caso a caso.

A primeira etapa deste processo, apesar de não ser obrigatória, é motivada pelo bom senso e por boas práticas de programa¸cão: o ajuste e consequente otimiza¸cão do estêncil, fazendo-o utilizar somente o espa¸co de memória necessário para o cálculo dos pontos. Para isso é utilizado o mesmo princ´ıpio de busca de padrões e substitui¸cão da etapa 2 e, nesse caso, é feita uma busca com uso do Regex por “u[...]”, que é transformado em “u[(...) % 3]”. Isso é feito somente no indexamento do tempo e garante uma aloca¸cão de memória bem menor que no caso onde isso não é feito.

A segunda etapa consiste em usar o SymPy para criar as declara¸c˜oes das vari´aveis utilizadas no algoritmo, e cria-se os ciclos “for”que iteram sobre o tempo e sobre os pontos da grade espacial, de modo que o resultado final seja basicamente aquele produzido pelo Devito.

Por último, usa-se o SymPy para construir a fun¸cão propriamente dita que contém o algoritmo. Nesta última etapa foi encontrado um obstáculo, pois o código gerado pelo Devito manda um objeto de um tipo particular (dataobj) e o primeiro comando da fun¸cão é a inicializa¸cão de um vetor com base no parâmetro desse objeto particular. E isso tudo, somado à keyword “restricted”e o operador de seta (− >), é sofisticado demais para ser gerado pelo SymPy, portanto foi necessário simplificar a manipula¸cão de dados.

Essa simplifica¸cão consistiu em reestruturar a fun¸cão principal do algoritmo e a estrutura de dados que contém os valores de problema de modo que toda a fun¸cão do algoritmo pudesse ser criada com uso do SymPy e de seus objetos. Essa cria¸cão, junto das etapas descritas acima, são confinadas a uma classe no código denominada “Generator”.

No fim das contas, essa reestrutura¸cão da fun¸cão rendeu um template final incrivel- mente simples, onde o único código literal é o header e a main, enquanto a fun¸cão de resolu¸cão de equa¸cão é completamente gerada, sendo substitu´ıda no template pelo ele- mento {{solver}}.

Abaixo encontram-se, respectivamente, o template e a fun¸c˜ao gerada:

#i n c l u d e ” s t d l i b . h” #i n c l u d e ”math . h”

i n t main ( ) {

d o u b l e myarray [ { { params . u s h a p e [ 0 ] } } ] [ { { params . u s h a p e [ 1 ] } } ] [ { { params . u s h a p e [ 2 ] } } ] = {{ params . u d a t a } } ;

S o l v e r ( { { params . dt } } , {{ params . s t e p x } } , {{ params . s t e p y } } , myarray , {{ params . max time } } , {{ params . m i n t i m e } } , {{ params . max x } } , {{ params . min x } } ,

{{ params . max y } } , {{ params . min y } } ) ;

r e t u r n 0 ; } i n t S o l v e r ( d o u b l e dt , d o u b l e h x , d o u b l e h y , d o u b l e u [ 3 ] [ 2 1 ] [ 2 1 ] , i n t time M , i n t time m , i n t x M , i n t x m , i n t y M , i n t y m ) { i n t t ; i n t x ; i n t y ; f o r ( t = time m ; t < time M ; t += 1 ) { f o r ( x = x m ; x < x M ; x += 1 ) { f o r ( y = y m ; y < y M ; y += 1 ) { u [ ( t + 1 ) % 3 ] [ x ] [ y ] = 1 . 0 ∗pow( dt , 2 ) ∗ ( −2.0∗u [ ( t ) % 3 ] [ x ] [ y ] /pow( h y , 2 ) + u [ ( t ) % 3 ] [ x ] [ y − 1 ] /pow( h y , 2 ) + u [ ( t ) % 3 ] [ x ] [ y + 1 ] /pow( h y , 2 ) − 2 . 0 ∗ u [ ( t ) % 3 ] [ x ] [ y ] /pow( h x , 2 ) + u [ ( t ) % 3 ] [ x − 1 ] [ y ] /pow( h x , 2 ) + u [ ( t ) % 3 ] [ x + 1 ] [ y ] /pow( h x , 2 ) + 2 . 0 ∗ u [ ( t ) % 3 ] [ x ] [ y ] /pow( dt , 2 ) − 1 . 0 ∗ u [ ( t − 1 ) % 3 ] [ x ] [ y ] /pow( dt , 2 ) ) ; } ; } ; } ; }

7 TESTES E AVALIAC¸ ˜AO

Dado que a estratégia de desenvolvimento deste projeto conta, em grande parte, com uma engenharia reversa do Devito, é natural que um dos principais meios de validá-lo seja através de compara¸cões diretas com o Devito em si, o que se dá em dois n´ıveis.

O primeiro n´ıvel de compara¸cão tem rela¸cão com a forma do código C gerado, ou seja, compara-se se o algoritmo gerado possui os mesmos, ou equivalentes, ciclos “for”, encar- regados de percorrer todas as itera¸cões necessárias em todas as dimensões do problema; e o mesmo, ou equivalente, centro do algoritmo, o estêncil que, através do indexamento expl´ıcito de um vetor multidimensional, atualiza o valor em cada posi¸cão do problema.

Analisando os códigos listados nos exemplos anteriores, é poss´ıvel perceber que eles são ligeiramente diferentes, mas, como explicado, essas diferen¸cas não acarretam em mudan¸ca de resultado desde que a fun¸cão “Kernel” e “Solve” sejam chamadas com os parâmetros ajustados, tanto em rela¸cão ao escopo das itera¸cões que serão usados no indexamento, quanto em rela¸cão à estrutura de dados que armazena os valores referentes à grade do problema.

Avaliar a forma do código, porém, apenas sugere a possibilidade de compatibilidade entre as respostas de cada versão, fazendo com que seja necessário uma compara¸cão efetiva entre os resultados obtidos em cada uma. O segundo n´ıvel de compara¸cão é justamente esse e ele compara todos os valores finais armazenados no vetor.

Para efetuar esse teste, utilizou-se de um lado o código gerado pelo programa através do template, cuja versão final se encontra na subse¸cão anterior, e de outro lado se utiliza a fun¸cão “Kernel” gerada pelo Devito, junto de uma fun¸cão main que contém exatamente os mesmos valores iniciais do problema. Esses valores, por sua vez, para que não fossem nulos como já comentado, foram inicializados através de uma fun¸cão de exemplo do próprio Devito. Esse método não precisa, e talvez nem deva, ser utilizado para inicializar os valores, podendo-se optar por qualquer outro meio, seja atribuindo valores literais no código, seja lendo de um arquivo, mas a t´ıtulo de exemplo, segue o método usado:

from e x a m p l e s . c f d import i n i t s m o o t h

i n i t s m o o t h ( f i e l d =u . d a t a [ 0 ] , dx=g r i d . s p a c i n g [ 0 ] , dy=g r i d . s p a c i n g [ 1 ] ) i n i t s m o o t h ( f i e l d =u . d a t a [ 1 ] , dx=g r i d . s p a c i n g [ 0 ] , dy=g r i d . s p a c i n g [ 1 ] )

Assim, temos uma grade inicial cujos valores no primeiro passo de tempo correspondem aos da figura 7, que foi desenhada com a fun¸c˜ao do Devito:

from e x a m p l e s . c f d import p l o t f i e l d p l o t f i e l d ( u . d a t a [ 0 ] )

Figura 7: Representa¸c˜ao da condi¸c˜ao inicial da grade de u no primeiro passo de tempo

Dada a configura¸cão inicial do problema, foi poss´ıvel chamar as respectivas fun¸cões de resolu¸cão com os devidos parâmetros que lhes garantem equivalência no tocante às itera¸cões realizadas e à estrutura de dados que armazena os valores. Essas chamadas, localizadas na main, foram:

K e r n e l ( 0 . 0 2 , 0 . 0 5 , 0 . 0 5 , &u v e c , 1 0 1 , 1 , 1 7 , 0 , 1 7 , 0 ) ;

S o l v e r ( 0 . 0 2 , 0 . 0 5 , 0 . 0 5 , myarray , 1 0 2 , 1 , 2 0 , 2 , 2 0 , 2 ) ;

Em seguida, para se comparar os valores resultantes de tais chamadas, simplesmente foi adicionado nos códigos uma pequena rotina para salvar os resultados em arquivos se- parados. A adi¸cão dessa rotina foi feita à mão apenas para a demonstra¸cão dos resultados, não constando no template de gera¸cão de código.

Finalmente, quando se compila e se executa o arquivo gerado (contendo, também, a rotina das respostas adicionada à mão), e o arquivo que combina a fun¸cão “Kernel” do Devito com uma main e a rotina, obtém-se dois arquivos contendo as respostas, um nomeado “myOutput” para os resultados que se deseja validar, e outro nomeado “answers” para os resultados esperados. Ambos os arquivos estão no formato:

. . .

u [ 1 ] [ 3 ] [ 1 3 ] 0 . 2 5 8 8 7 9 u [ 1 ] [ 3 ] [ 1 4 ] 0 . 0 4 8 7 2 1

u [ 1 ] [ 3 ] [ 1 5 ] −0.003954 . . .

Para se comparar todos os valores gerados, foi escrita uma pequena rotina em Python que itera sobre cada linha de cada arquivo comparando-as uma a uma. O retorno dessa rotina foi:

P e r c e n t a g e o f c o r r e c t a n s w e r s : 100.0% ( 1 3 2 3 / 1 3 2 3 ) ´

E preciso dizer, porém, que a compara¸cão entre os resultados foi feita com uma margem de erro, onde se aceitava como igual aqueles valores com uma diferen¸ca menor que 0.00001. No caso de se comparar os valores exatos, o resultado obtido é pior (65%), dado que pequenas diferen¸cas na ordem dos cálculos executados pelo estêncil em cada versão podem acarretar em leves diferen¸cas no resultado final.

No fim das contas, como os resultados são praticamente iguais, foi feito o desenho da grade na última itera¸cão do tempo apenas uma vez, mostrado na figura 8 apenas para efeitos de ilustra¸cão:

Figura 8: Representa¸cão da condi¸cão final da grade de u no último passo de tempo

Esse resultado, portanto, valida a equivalência de funcionamento entre a fun¸cão gerada pelo Devito e pelo projeto aqui desenvolvido. Apesar de ligeiramente diferentes, ambos os códigos produzem os mesmos resultados somente na condi¸cão de serem executados o mesmo número de itera¸cões sobre cada dimensão do problema, ou seja, apenas (e logica-

mente) na condi¸cão de se executarem os mesmos cálculos o mesmo número de vezes, o que pode ser feito com chamadas de fun¸cão ajustadas para cada versão.

Por outro lado, e apesar desse ótimo resultado, não se pode omitir que quando se obtém os valores da grade usando o objeto “Operator” do Devito, e não através de um código que usa a fun¸cão por ele gerada, os resultados são significativamente piores. Caso se use a mesma tolerância de 0.00001, a taxa de acerto fica 18%. Caso se use uma tolerância de 0,1, a porcentagem de acerto fica 22%. Só uma tolerância de 1 deixa a taxa de acerto aceitável (88%).

O motivo dessa enorme discrepância é desconhecido, mas provavelmente acontece por conta de alguma diferen¸ca no escopo das itera¸cões realizadas internamente pelo Devito. Infelizmente, não se pôde ir mais a fundo nas causas reais desse problema, pois o Devito tem um funcionamento de dif´ıcil compreensão em certos aspectos, assemelhando-se a uma caixa preta, e isso evidencia mais uma vez a necessidade que também é meta deste projeto de se desvencilhar do Devito, proporcionando uma solu¸cão semelhante, mas de fácil compreensão, utiliza¸cão, integra¸cão, e evolu¸cão.

Por fim, para mostrar que, apesar das diferen¸cas consideráveis, os resultados ainda são razoavelmente compat´ıveis, a figura 9 ilustra a grade gerada pelo “Operator”, que se assemelha à figura anterior.

8 CONSIDERAC¸ ˜OES FINAIS

8.1 Conclus˜oes do Projeto de Formatura

Uma análise retrospectiva do que foi e não foi atingido ao longo do projeto deve avaliar, em um plano mais genérico, se a proposta que intitula o projeto foi de fato implementada, e em um plano mais espec´ıfico, se cada grande passo de desenvolvimento definido no planejamento foi realmente alcan¸cado.

O tema central do projeto é a “gera¸cão de código C para a resolu¸cão de equa¸cões de onda representadas em uma DSL através do método de diferen¸cas finitas”, e para explicar se e em que medida isso foi atingido é necessário decompor o t´ıtulo em peda¸cos menores, os quais se encaixam propositalmente bem nos passos definidos no planejamento.

O primeiro passo, no t´ıtulo “[...] equa¸cões de onda representadas em uma DSL [...]”, não se trata propriamente de uma nova implementa¸cão que devesse ser realizada, mas sim de uma tarefa essencial e preliminar para dar in´ıcio ao problema, para formalizar a parte matemática do problema.

A grande questão aqui se resumiu a escolher o modelo de equa¸cão de onda que seria utilizado e representa-lo usando uma DSL. E isso, como demonstrado, foi executado sem grandes problemas, de forma simples e direta. A equa¸cão escolhida foi a clássica equa¸cão de onda, e sua representa¸cão na DSL do Devito é suficientemente intuitiva, a ponto de ser facilmente reproduzida ou alterada para expressar equa¸cões mais complexas.

Ainda neste primeiro passo, abordou-se parte da questão da “resolu¸cão [...] através do método de diferen¸cas finitas”, pois além de se representar a equa¸cão de forma simbólica, o Devito fornece os meios de se representar o estêncil que resolve a equa¸cão por diferen¸cas finitas, o que novamente se dá de modo simples e direto.

O segundo passo se refere à tradu¸cão da DSL com o SymPy, o que faz evidente re- ferência à representa¸cão da equa¸cão. A tradu¸cão final alcan¸cada pelo analisador sintático desenvolvido é genérica o suficiente para se aplicar a outras equa¸cões diferenciais parciais, de modo que o problema original pode ser alterado e expandido com pouca ou nenhuma dificuldade.

Porém, ainda que o Parser criado permita trabalhar com uma maior gama de problemas, a gera¸cão de código ainda não igualou tal abrangência. Esse aspecto da “gera¸cão do código C para a resolu¸cão de equa¸cões [...]” é tratado pelo terceiro e quarto passos em diferentes graus de complexidade.

O código gerado pela terceira parte garante apenas que um código compilável possa de fato ser produzido pela aplica¸cão, mesmo que esse código seja majoritariamente estático,

ou seja, escrito literalmente no template. Apesar disso, esse código assegura a correta transferência dos dados criados no código Python para o código C.

Já o código gerado pela quarta parte almeja tornar o código gerado o mais flex´ıvel poss´ıvel, possibilitando a resolu¸cão de equa¸cões que necessitem de algoritmos ligeiramente diferentes caso a caso.

Foi apenas nessa última etapa onde não foi poss´ıvel atingir um alto n´ıvel de implementa¸cão, dada a brevidade de tempo dispon´ıvel para um desenvolvimento completo. O que foi desenvolvido é limitado quanto às formas de equa¸cão que teriam um algoritmo de resolu¸cão gerado corretamente, e isso se dá por dois motivos. Primeiro, a gera¸cão de código não consegue lidar com 3 dimensões espaciais, dado que nesse caso ela deveria incluir um novo ciclo de itera¸cão sobre a dimensão z, o que ela não faz; segundo, a gera¸cão de código não suporta estênceis de ordens diferentes, dado que eles acarretam em uma mudan¸ca no número de pontos usados para se calcular o ponto em questão. Esse comportamento leva, por conta de mudan¸cas no indexamento, a uma mudan¸ca nos limites das itera¸cões em cada dimensão e, também, pode invalidar a otimiza¸cão de espa¸co de memória na dimensão do tempo, que usa apenas 3 pontos. Contudo, foi poss´ıvel, sim, gerar um código em grande parte dinâmico, produzido especificamente para equa¸cões diferenciais parciais de segunda ordem, dado que suas solu¸cões obedecem um algoritmo uniforme. Além disso, todas essas limita¸cões descritas são razoavelmente simples de serem implementadas com um tempo de desenvolvimento adequado.

Retrospectivamente, é poss´ıvel afirmar que o que foi implementado fornece os meios para representar uma equa¸cão de onda com uma DSL, para resolve-la usando o método de diferen¸cas finitas, e para gerar o código C que a resolve, cumprindo todas as exigências do tema principal. O que foi proposto, então, foi plenamente atingido, com a ressalva de que não se atingiu um grau de complexidade e abrangência muito altos, mas suficientes, e aquilo que foi atingido foi validado por testes coerentes. Além disso, o presente documento em si serve múltiplos propósitos: ele contempla de forma organizada e sintetizada o vasto campo de contextualiza¸cão do problema em questão, introduzindo o leitor ao complexo problema de imageamento s´ısmico e muito do que lhe é impl´ıcito; ele contempla uma descri¸cão direcionada das principais ferramentas utilizadas, conduzindo o leitor às funcionalidades de maior interesse na vasta documenta¸cão do SymPy e Devito; e, claro, ele contempla a descri¸cão minuciosa e, espera-se, didática do projeto em si, possibilitando o leitor de fazer uma transi¸cão sem grandes esfor¸cos para uma outra aplica¸cão, e de dar continuidade ao projeto, evoluindo a complexidade e abrangência que ainda lhe faltam.

8.2 Contribui¸c˜oes

Ficou evidente ao longo deste documento que o projeto tem fortes ra´ızes no SymPy e no Devito, fazendo uso essencial de inúmeras de suas funcionalidades para atingir uma meta que, de um modo ou de outro, já é realizada pelo Devito, que por sua vez faz grande uso do SymPy. Neste projeto, portanto, não foi criada e desenvolvida uma maneira original de lidar com expressões simbólicas, ou de representar equa¸cões matemáticas.

Aquilo que foi propriamente criado neste projeto foi um analisador sintático que tra- duz as expressões simbólicas descritas com a DSL do Devito para expressões simbólicas próprias do SymPy e, em seguida, para sua forma representativa em código C. Em outras palavras, esse projeto possibilita que determinados problemas matemáticos que envolvem equa¸cões diferenciais parciais, e que foram facilmente formalizados em alto n´ıvel com a conveniência do Devito, possam ser transformados em seu formato de baixo n´ıvel em linguagem C através do SymPy.

Como já mencionado, essa mesma fun¸cão já é executada pelo próprio Devito, com a diferen¸ca que ele busca fazer otimiza¸cões computacionais no código gerado. Aqui, porém, almejava-se justamente suprimir essas otimiza¸cões, deixando-a a cargo de especialistas que podem executá-las especificamente para o hardware e para o problema em questão.

Isso acarreta na segunda contribui¸cão do projeto, que foi, através de uma engenharia reversa do Devito, proporcionar uma solu¸cão paralela para o problema da resolu¸cão de equa¸cões de onda na forma de um algoritmo em código C. É esse resultado que permitirá o uso do que foi aqui desenvolvido em aplica¸cões da área de modelagem e simula¸cão de modelos s´ısmicos. É esse o produto que pode ser inserido em outros contextos e otimizado conforme os requisitos espec´ıficos de outros problemas.

Finalmente, deve-se adicionar que o código e a documenta¸cão produzidos contribuem para o diálogo entre as diferentes partes envolvidas em projetos de imageamento s´ısmico. Espera-se, assim, que f´ısicos, matemáticos, geólogos, e programadores, possam ser bene- ficiados em rela¸cão ao seu conhecimento do problema, à sua comunica¸cão de ideias, e às suas solu¸cões de problemas.

8.3 Perspectivas de Continuidade

Resta, finalmente, recapitular aquilo que pode ser melhorado e/ou evolu´ıdo neste projeto e o primeiro passo l´ogico ´e analisar o que foi apenas parcialmente atingido.

E evidente, então, a possibilidade de evolu¸cão do quarto grande passo determinado no planejamento. Sua implementa¸cão ideal possibilitaria que qualquer equa¸cão diferencial parcial fosse resolvida através de um código que foi gerado para aquele caso espec´ıfico,

não importa o grau da equa¸cão e a ordem de seu estêncil.

Um segundo ponto com clara possibilidade de evolu¸cão seria a complexidade da en- trada do problema. No estado atual, lida-se apenas com uma equa¸cão de onda, como foi proposto, e nada mais. Em um estado mais avan¸cado, seria esperado que o programa possu´ısse a capacidade de se adequar para modelos s´ısmicos completos, formalizados através de uma expressão matemática que inclu´ısse as fontes das ondas sonoras, os receptores de seus reflexos, condi¸cões de borda, e geometrias mais complexas. Isso, logicamente, acarretaria em grandes mudan¸cas no código gerado, dado que o algoritmo de resolu¸cão deverá levar em conta todos esses aspectos mais complexos. O analisador sintático, porém, provavelmente precisaria de mudan¸cas menos drásticas já que ele é en- carregado de traduzir aspectos que já são comuns ao problema atual e a este problema futuro hipotético.

Sintetizando o que foi descrito, seria poss´ıvel incrementar e evoluir o projeto atual para um estado em que ele se assemelhe ao Devito com rela¸cão à abrangência de problemas s´ısmicos que ele suporta, apesar de resolvê-los à sua maneira e não contemplar otimiza¸cões computacionais.

REFERˆENCIAS

1 ONAJITE, E. Chapter 2 - understanding seismic wave propagation. In: ONAJITE, E. (Ed.). Seismic Data Analysis Techniques in Hydrocarbon Exploration. Oxford: Elsevier, 2014. p. 17 – 32. ISBN 978-0-12-420023-4.

2 ONAJITE, E. Chapter 13 - understanding seismic interpretation methodology. In: ONAJITE, E. (Ed.). Seismic Data Analysis Techniques in Hydrocarbon Exploration. Oxford: Elsevier, 2014. p. 177 – 211. ISBN 978-0-12-420023-4.

3 ONAJITE, E. Chapter 3 - understanding seismic exploration. In: ONAJITE, E. (Ed.). Seismic Data Analysis Techniques in Hydrocarbon Exploration. Oxford: Elsevier, 2014. p. 33 – 62. ISBN 978-0-12-420023-4.

4 VIRIEUX, J.; OPERTO, S. An overview of full-waveform inversion in exploration geophysics. Geophysics, Society of Exploration Geophysicists, v. 74, n. 6, p.

WCC1–WCC26, 2009.

5 CARCIONE, J.; HERMAN, G.; KROODE, A. ten. Seismic modeling: Geophysics. [S.l.]: GPYSA7, 2002.

6 BIEZUNER, R. J. Equa¸c˜oes diferenciais parciais i/ii. 2011.

7 LANGTANGEN, H. P. Finite Difference Computing with Exponential Decay Models. [S.l.]: Springer Nature, 2016.

8 YOUNT, C. et al. Yask—yet another stencil kernel: A framework for hpc stencil code- generation and tuning. In: IEEE. 2016 Sixth International Workshop on Domain-Specific Languages and High-Level Frameworks for High Performance Computing (WOLFHPC). [S.l.], 2016. p. 30–39.

9 DEURSEN, A. V.; KLINT, P. Domain-specific language design requires feature descriptions. Journal of computing and information technology, SRCE-Sveuˇciliˇsni raˇcunski centar, v. 10, n. 1, p. 1–17, 2002.

10 LANGE, M. et al. Devito: Towards a generic finite difference dsl using symbolic

No documento RAPHAEL CHYPRIADES JUNQUEIRA AMARANTE DE EQUAÇÕES DE ONDA REPRESENTADAS EM UMA DSL ATRAVÉS DO MÉTODO DE DIFERENÇAS FINITAS (páginas 44-54)