Embed Size (px)
Citation preview
SISTEMA DE GERÊNCIA DE WORKFLOW CIENTÍFICO APLICADO AO
IMAGEAMENTO SÍSMICO
Luciano Silva Leite
Projeto de Graduação apresentado ao Curso de
Engenharia de Computação e Informação da Escola
Politécnica, Universidade Federal do Rio de Janeiro,
como parte dos requisitos necessários à obtenção do
título de Engenheiro.
Orientadores: Marta Lima de Queirós Mattoso
Orientadores: Danilo Leite Costa
Rio de Janeiro
Março de 2015
ii
SISTEMA DE GERÊNCIA DE WORKFLOW CIENTÍFICO APLICADO AO
IMAGEAMENTO SÍSMICO
Luciano Silva Leite
PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO
CURSO DE ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA ESCOLA
POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO
PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE
ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO.
Examinada por:
________________________________________________
Prof.ª Marta Lima de Queirós Mattoso, D.Sc.
________________________________________________
Prof. Felipe Maia Galvão França, Ph.D.
________________________________________________
Vítor Silva Sousa, M.Sc.
________________________________________________
Danilo Leite Costa, M.Sc.
RIO DE JANEIRO, RJ - BRASIL
MARÇO de 2015
iii
Leite, Luciano Silva
Sistema de Gerência de Workflow Científico Aplicado
ao Imageamento Sísmico / Luciano Silva Leite. – Rio de
Janeiro: UFRJ/ Escola Politécnica, 2015.
IX, 50 p.: il.; 29,7 cm.
Orientadores: Marta Lima de Queirós Mattoso e Danilo
Leite Costa
Projeto de Graduação – UFRJ/ Escola Politécnica/ Curso
de Engenharia de Computação e Informação, 2015.
Referências Bibliográficas: p. 48-50.
1. Workflows Científicos 2. Migração Reversa no
Tempo 3. Imageamento Sísmico I. Mattoso, Marta Lima de
Queirós et al. II. Universidade Federal do Rio de Janeiro,
Escola Politécnica, Curso de Engenharia de Computação e
Informação. III. Título.
iv
DEDICATÓRIA
À minha mãe e ao meu pai pelo apoio e incentivo.
v
AGRADECIMENTOS
Agradeco a minha mãe, por me incentivar, inspirar e ajudar a vencer este e
outros desafios ao longo da minha vida.
Agradeço a todos os meus professores que se dedicam a esta profissão.
Agradeço em especial à professora orientadora Marta Mattoso, por aceitar orientar este
projeto, e ao professor Felipe França, por participar da banca.
Agradeço ao Vítor Silva pela generosidade e disposição em contribuir com este
trabalho e em compartilhar conhecimento.
Agradecos aos funcionários e colaboradores da PETREC por compartilharem
seus conhecimentos em sísmica e computação de alto desempenho. Agradeço em
especial, ao co-orientador deste trabalho, Danilo, pelo incentivo, apoio, paciência e
generosidade.
Agradeço aos amigos que fiz neste curso, por terem contribuído muito para que
eu me tornasse engenheiro.
vi
Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como parte
dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e
Informação.
Sistema de Gerência de Workflow Científico Aplicado ao Imageamento
Sísmico
Luciano Silva Leite
Março/2015
Orientadores: Marta Lima de Queirós Mattoso
Orientadores: Danilo Leite Costa
Curso: Engenharia de Computação e Informação
Os experimentos científicos têm utilizado Sistemas de Gerência de Workflows
Científicos (SGWfC) com o intuito de apoiar a modelagem, execução e análise dos
mesmos. Sendo assim, os experimentos científicos têm sido modelados por meio de
workflows científicos. Um workflow científico consiste de um conjunto de programas e
serviços específicos com o intuito de atender um determinado objetivo no experimento,
ao mesmo tempo em que pode haver dependências de dados entre esses diferentes
programas e serviços. Nesse sentido, o presente trabalho apresenta a modelagem, a
execução e a análise de um experimento científico de modelagem sísmica RTM
(Reverse Time Migration) usando o Chiron, um SGWfC paralelo. O procedimento de
modelagem envolve a fragmentação do código do programa de sísmica de modo que se
obtenha um conjunto de programas que, encadeados, produzam o mesmo resultado do
programa original. Esta abordagem favorece o paralelismo, processamento de consultas
e análise da base de proveniência. A viabilidade da solução desenvolvida é avaliada
através de testes para garantir a correta execução do algoritmo e avaliar seu desempenho
em ambiente de processamento de alto desempenho.
Palavras-chave: Migração Reversa no Tempo, Workflows Científicos, Imageamento
Sísmico.
vii
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of
the requirements for the degree of Engineer.
Scientific Workflow Management Systems Applied to Seismic Imaging
Luciano Silva Leite
March/2015
Advisors: Marta Lima de Queirós Mattoso
Advisors: Danilo Leite Costa
Major: Computer and Information Engineering
Scientific experiments use Scientific Workflow Management Systems (SWMS) in order
to support their modelling, execution and analysis. Thus, scientific experiments have
been modelled as scientific workflows. A scientific workflow consists in a set of
programs and services that fulfill specific purposes in the experiment. Whereas, may
exists data dependencies between those programs and services. In face of this, this work
presents modeling, execution and analysis of a scientific experiment of Reverse Time
Migration (RTM) seismic modeling using Chiron, a parallel SWMS. The process of
modeling the experiment, involves breaking the source code to produce a set of smaller
programs that, chained, generate the same output of the original application. This
approach promotes the parallelism, query processing and provenance database analysis.
The availability of the developed solution is evaluated through tests to assure the
correctness of the algorithm, and evaluate its performance in a high performance
computing environment.
Keywords: Reverse Time Migration, Scientific Workflow Management Systems,
Seismic Imaging
viii
SUMÁRIO
1. Introdução ................................................................................................................ 1
1.1 Sistemas de Gerência de Workflows Científicos ................................................ 2
1.2 Imageamento Sísmico ......................................................................................... 4
1.3 Objetivos do Trabalho ......................................................................................... 5
2. Trabalhos Relacionados ........................................................................................... 7
2.1 Implementação MapReduce da Migração Kirchhoff .......................................... 8
2.2 Suporte ao Paralelismo em Processamento Sísmico ........................................... 9
2.3 DECF: Uma Plataforma composição e execução de experimentos de
Processamento Sísmico ...................................................................................... 10
3. Chiron .................................................................................................................... 12
3.1 Modelo de Representação: Álgebra de Workflows .......................................... 14
3.2 Modelo de Execução de uma Ativação ............................................................. 16
3.3 Modelo de Proveniência.................................................................................... 18
3.4 Estratégias de Escalonamento ........................................................................... 19
3.5 Modelagem de Workflows ................................................................................ 21
4. Migração Reversa no Tempo ................................................................................. 23
4.1 Aspectos Computacionais ................................................................................. 28
5. Modelagem das Atividades do Workflow ............................................................. 31
5.1 Workflow Modelagem RTM ............................................................................ 31
5.2 Workflow Migração Sísmica ............................................................................ 33
5.3 Pós-processamento ............................................................................................ 36
6. Análise Experimental ............................................................................................ 38
6.1 Configuração dos Experimentos ....................................................................... 39
ix
6.2 Consultas à base de proveniência ...................................................................... 42
7. Conclusão .............................................................................................................. 46
Referências Bibliográficas ........................................................................................... 48
1
1. Introdução
Experimentos científicos envolvendo simulações computacionais em larga
escala são conduzidos em áreas como bioinformática (STEVENS, MCENTIRE, et al.,
2004), astronomia (JACOB, KATZ, et al., 2009) e a exploração de petróleo em águas
profundas (DA SILVA e SENGER, 2009). Em geral, tais experimentos podem ser
compreendidos como o encadeamento de programas e serviços, que produzem e
consomem grandes quantidades de dados, executados em ambientes de Processamento
de Alto Desempenho (PAD).
Gerenciar o encadeamento de programas e a grande quantidade de dados
manipulada ao longo da modelagem e execução do experimento é uma dificuldade
comum neste cenário. Para facilitar a gerência das etapas do experimento, é comum o
uso do conceito workflow científico, que significa abstrair o experimento como um
conjunto de atividades e um fluxo de dados entre elas.
O termo workflow tem suas origens na década de 70, associadas aos processos
de automação de escritórios. O foco desta tecnologia era oferecer soluções para
diminuir a geração e distribuição de documentos em papel em uma organização. Neste
contexto, um workflow pode ser compreendido como a automação total ou parcial de
um processo de negócios no qual documentos, informações ou tarefas são passadas de
uma entidade para outra de acordo com um conjunto de regras (AALST e HEE, 2002).
Mais recentemente, o conceito de workflow vem sendo aplicado às ciências, na
automação de experimentos computacionais que necessitam de grande poder de
processamento e manipulam grande quantidade de dados entre repositórios,
possivelmente, distribuídos. Enquanto os workflows de negócios representam processos
2
bem definidos dentro da estrutura de uma organização, os workflows científicos tendem
a ser mais mutáveis, devido à necessidade de adaptação, aprimoramento, reuso e
compartilhamento, como é comum na comunidade científica. (BARGA, FAY, et al.,
2008).
O paradigma de workflow científico é útil na descrição, análise, gerência e
compartilhamento de simulações computacionais. Os workflows científicos são,
geralmente, especificados através de linguagens de alto nível que permitem definir quais
os objetivos do workflow, os dados necessários para execução de cada atividade, bem
como as dependências entre elas. Nesse contexto, um workflow pode ser definido como
um grafo direcionado e acíclico (DAG, do inglês Directed Acyclic Graph), no qual os
vértices e arestas representam as atividades e suas dependências em relação à produção
e ao consumo de dados, respectivamente (BROWN, BRADY, et al., 2007).
1.1 Sistemas de Gerência de Workflows Científicos
Os Sistemas de Gerência de Workflows Científicos (SGWfC) surgiram para
auxiliar a composição, o monitoramento e a visualização de workflows (BERRIMAN,
DEELMAN, et al., 2007, DIAS, OGASAWARA, et al., 2013, OCAÑA, DE
OLIVEIRA, et al., 2011). É comum a utilização de SGWfC em áreas científicas que
manipulam experimentos de larga escala, como na astronomia (BERRIMAN,
DEELMAN, et al., 2007) e na quantificação de incerteza (GUERRA, ROCHINHA, et
al., 2009). Existem vários SWGfC com características e comportamentos distintos,
como o VisTrails (CALLAHAN, FREIRE, et al., 2006) o Taverna (MISSIER,
SOILAND-REYES, et al., 2010), o Swift/T (WOZNIAK, ARMSTRONG, et al., 2013),
o Kepler (LUDÄSCHER, ALTINTAS, et al., 2006), o Pegasus (DEELMAN, MEHTA,
3
et al., 2007), o Chiron (OGASAWARA, DIAS, et al., 2013) e o Galaxy (GOECKS,
NEKRUTENKO, et al., 2010).
Para gerenciar e monitorar os workflows, os SGWfC precisam capturar dados de
proveniência, isto é, dados relativos à modelagem (i.e. proveniência prospectiva) e à
execução (i.e. proveniência retrospectiva) do workflow (FREIRE, KOOP, et al., 2008).
Os SGWfC devem dispor informações sobre a origem dos dados, como foram alterados
e que parâmetros forma utilizados em seu processamento de maneira que permita o
controle dos resultados e possibilite a reprodutibilidade do experimento científico.
Em geral, os experimentos científicos requerem grande poder computacional,
por isto, costumam ser executados em ambientes de PAD, como clusters, grids e clouds.
Os recursos em ambientes de PAD são caros e disputados, por isto, é preciso usá-los da
melhor maneira possível. O desenvolvedor precisa lidar com algumas dificuldades
associadas ao uso destes ambientes como evitar deixar recursos ociosos, evitar que um
experimento falhe e monitorar o progresso da execução do experimento. Dentre as
alternativas mais populares para que as aplicações tirem proveito do poder
computacional destas arquiteturas paralelas, pode-se citar o uso de plataformas de
paralelismo como as bibliotecas OpenMP e Message Passing Interface (MPI) no
código.
Os SGWfC paralelos permitem que o cientista desenvolva seu experimento em
larga escala com programas sequenciais e abstraia de questões ligadas a execução em
ambientes de PAD, pois oferecem suporte tanto à execução paralela quanto ao
monitoramento de workflows, garantindo confiabilidade e robustez.
Portanto, os SGWfC paralelos são capazes de executar um workflow de maneira
paralela mesmo quando os programas que compõem o workflow são sequenciais. Em
4
geral, os SGWfC adotam paralelismo de dados para se beneficiar dos recursos de PAD
sem que os programas que o compõem sejam paralelos. Isto significa que os nós
computacionais (NC) disponíveis irão executar instâncias dos mesmos programas com
conjuntos de dados diferentes (BUX e LESER, 2013).
1.2 Imageamento Sísmico
As aplicações de imageamento sísmico buscam revelar informações sobre as
estruturas geológicas sob a superfície terrestre e estão entre as maiores demandas por
computação de alto desempenho na indústria de óleo e gás. O processo de imageamento
sísmico inicia-se pela aquisição de dados, que consiste em produzir ondas
compressionais no solo e gravar as ondas refletidas de volta para a superfície. Como
este procedimento cobre milhares de quilômetros quadrados, é necessário armazenar
dezenas de terabytes de dados. Estes dados servem como entrada para os algoritmos de
migração sísmica, que produzem imagens da terra, onde é possível identificar as
estruturas geológicas. Estas imagens são interpretadas por especialistas para auxiliar na
decisão de onde deve ser feita a perfuração de novos poços de extração de óleo e gás
(RIZVANDI, BOLOORI, et al., 2011).
Existem diversos algoritmos de migração sísmica, que variam em relação ao
modelo físico-matemático que adotam para representar as propriedades da Terra e para
simular a propagação da onda. A escolha de modelos mais complexos possibilita gerar
imagens com maior qualidade. Contudo, a complexidade do modelo utilizado no
algoritmo da migração sísmica também aumenta seu custo computacional (ZHAO,
YAN, et al., 2008).
Levando em conta o alto custo do processo de perfuração e a o fato da precisão
das imagens geradas pela migração minimizar os riscos de insucesso na perfuração,
5
produzir imagens sísmicas de alta qualidade pode representar uma economia de milhões
de dólares (RIZVANDI, BOLOORI, et al., 2011). Assim, a importância estratégica do
imageamento sísmico justifica o esforço em desenvolver algoritmos, técnicas e
estratégias que possibilitem gerar imagens com a qualidade desejada.
1.3 Objetivos do Trabalho
Este trabalho tem por objetivo integrar as vantagens e recursos de um SGWfC
paralelo a experimentos de imageamento sísmico. O trabalho descreve como os
workflows foram modelados a partir das aplicações originais. Os experimentos
computacionais de imageamento sísmico de subsuperfície oceânica para avaliação do
perfil geológico são atividades que podem se beneficiar das vantagens oferecidas pelos
SGWfC. Uma vez que o processamento de dados sísmicos utiliza workflows que
envolvem manipulação e processamento de grandes volumes de dados, é necessário
utilizar técnicas de paralelismo e tecnologias que apoiem a execução de milhares de
simulações em ambientes de PAD e manipulação de centenas de terabytes de dados de
entrada e saída.
O presente trabalho descreve a modelagem de workflows para dois experimentos
de imageamento sísmico que utilizam a técnica migração reversa no tempo (RTM, do
inglês, Reverse Time Migration): a modelagem sísmica isotrópica e a migração reversa
no tempo TTI (do inglês, Transverse Tilted Isotropy). A modelagem de workflows
consiste em especificar como é o encadeamento das atividades que compõem o
experimento e suas dependências. Para obter melhor proveito das funcionalidades
oferecidas pelo SGWfC, são necessárias ainda adaptações no código-fonte das
aplicações, além da construção de rotinas para extração de informações sobre produção
6
e consumo de dados. Como aplicações originais que utilizam as bibliotecas MPI para
distribuir tarefas entre vários NC computacionais e OpenMP para implementar
paralelismo intra-nó, também é necessário ajustar o comportamento da aplicação no que
diz respeito ao paralelismo.
O desempenho da solução desenvolvida será avaliado pelo impacto do SGWfC
no tempo de execução do experimento de processamento sísmico, já que este é um fator
crítico na execução de experimentos RTM, visto que a produção de imagens sísmicas
em tempo hábil é necessária para apoiar decisões na indústria de óleo e gás. Também
será avaliada a possibilidade de monitoramento do workflow pela extração e gerência
eficiente de informações sobre a execução do experimento.
Para tal, pretende-se empregar o Chiron (OGASAWARA, DIAS, et al., 2013),
um SGWfC paralelo desenvolvido pelo Núcleo de Computação de Alto Desempenho
(NACAD), laboratório da COPPE/UFRJ. No Chiron, a especificação dos workflows é
feita através da álgebra relacional de workflows científicos, proposta por
OGASAWARA, OLIVEIRA, et al. (2011). Essa álgebra representa as transformações
de dados pelas atividades através da abstração de consumo e produção de tuplas. E, por
meio desta característica, promove o acesso aos dados de proveniência de maneira
estruturada, num banco de dados relacional, durante e após a execução do workflow.
7
2. Trabalhos Relacionados
Os artigos descritos neste capítulo tratam de outras soluções que apoiam a
realização de experimentos científicos na área de sísmica. Embora as publicações não
envolvam ou mencionem SGWfC, seus autores reconhecem os desafios relacionados à
realização de experimentos computacionais que incluem simulações de fenômenos
geofísicos em ambiente de PAD. As soluções descritas neste capítulo não incluem
SGWfC, contudo, buscam solucionar, com outras abordagens, as dificuldades em
realizar experimentos de simulação sísmica em larga escala.
Dentre as principais contribuições almejadas pelas soluções podemos citar o
apoio ao paralelismo, à execução em ambientes de PAD, mecanismos de recuperação de
falhas e o apoio à configuração do experimento (encadeamento de atividades) como
objetivos comuns entre as soluções descritas neste capítulo e a solução desenvolvida
neste trabalho. Entretanto, o Chiron, SGWfC usado nesta proposta, para modelar e
gerenciar experimentos de imageamento sísmico apresenta recursos mais elaborados
para configuração do experimento e permite acesso à proveniência, ponto que é
abordado apenas por RODRIGUEZ, HANZICH, et al., (2013).
RIZVANDI, BOLOORI, et al. (2011), RODRIGUEZ, HANZICH, et al.
(2013), ZHAO, YAN, et al. (2008) propõem soluções que exercem a gerência da
execução paralela de algoritmos relacionados ao imageamento sísmico. Nos três artigos,
o exemplo utilizado é a Migração Kirchhoff (PKTM, do inglês Prestack Kirchhoff Time
Migration). Sua complexidade computacional é menor dentre os algoritmos utilizados
para imageamento sísmico. Em contrapartida, métodos computacionalmente mais
custosos como a Migração Reversa no Tempo produzem imagens com grau de precisão
maior e com mais riqueza de detalhes.
8
2.1 Implementação MapReduce da Migração Kirchhoff
RIZVANDI, BOLOORI, et al. (2011) propõem uma implementação do
algoritmo da Migração Kirchhoff (PKTM, do inglês Prestack Kirchhoff Time
Migration) em ambiente distribuído usando o Google MapReduce, um modelo de
programação para processamento de grandes volumes de dados com algoritmos
paralelizados em ambiente de PAD. O MapReduce é responsável por gerenciar o
processamento em sistemas de PAD distribuindo tarefas, controlando a comunicação e a
transferência de dados entre os componentes do sistema (DEAN e GHEMAWAT,
2008). As funcionalidades mais marcantes deste modelo de programação são
paralelização automática, facilidade de implementação e tolerância a falhas.
A infraestrutura do MapReduce é ideal para processar algoritmos que podem
ser fragmentados em operações menores e independentes. A execução passa por duas
etapas: map e reduce. A etapa de map é computacionalmente intensiva, os dados
particionados são processados e na etapa reduce os resultados da etapa anterior são
combinados num resultado global e após o término das duas etapas o resultado é
gravado em um sistema de arquivos. A estratégia MapReduce foi pensada para
ambientes com NC com capacidade de processamento limitada, porém, em grande
número. Por esta razão, costuma alcançar melhor desempenho paralelizando algoritmos
cuja complexidade é baixa ou moderada mas o volume de dados é grande e pode ser
fragmentado em vários volumes menores. A Migração Kirchhoff atende todas as
características esperadas de um algoritmo candidato a ser implementado no modelo de
programação MapReduce. O fluxo do algoritmo da PKTM pode ser fragmentado em
tarefas menores independentes, sendo que seus dados de entrada tipicamente ocupam
terabytes.
9
A implementação PKTM foi desenvolvida utilizando o Apache Hadoop,
implementação de código aberto testada em um único notebook que sustentou todos os
módulos do Hadoop distribuídos em seus núcleos. Neste sistema pseudo distribuído, o
autor avaliou o tempo de execução do algoritmo de acordo com o número de instâncias
das funções map e reduce por processador. O resultado dos testes mostra que a melhor
configuração é a que executa uma instância por processador, para as duas fases.
2.2 Suporte ao Paralelismo em Processamento Sísmico
RODRIGUEZ, HANZICH, et al. (2013) propõem um modelo de
desenvolvimento baseado nos princípios da metodologia ágil (AMBLER, 2002) com o
objetivo de apoiar o desenvolvimento de experimentos em sísmica em ambiente
distribuído, gerenciando aspectos que fogem ao escopo da sísmica. Este sistema é
composto por três módulos principais: distribuição de tarefas, interface de suporte
programação de aplicações, controle de status.
O módulo de distribuição de tarefas é responsável por controlar a infraestrutura
computacional. Este módulo define a função (role) dos NC, isto é, que programas
podem ser executados por cada NC, distribui as tarefas para os recursos disponíveis, e
realiza operações de checkpointing responsáveis por recuperação de falhas.
Resumidamente, os papéis possíveis são de processamento e pós-processamento. Os NC
com função de processamento, normalmente recebem tarefas mais pesadas como
migrações e modelagens. Os NC de pós-processamento são responsáveis por executar
rotinas que compõem resultados gerados por várias execuções dos NC de
processamento. A interface de suporte programação de aplicações oferece uma
biblioteca de funcionalidades para manipular dados sísmicos como leitura de traços
sísmicos, interpolações e filtros.
10
O módulo de monitoramento oferece, através da arquitetura cliente-servidor, a
possibilidade de monitorar e alterar parâmetros do experimento em tempo de execução,
até mesmo a quantidade de recursos alocados. Como os experimentos sísmicos levam
meses executando, as possibilidades de monitorar a execução e alterar parâmetros sem
interrompê-la são muito úteis. Este recurso permite, por exemplo, redirecionar parte dos
recursos alocados para alguma tarefa com maior prioridade.
2.3 DECF: Uma Plataforma composição e execução de experimentos
de Processamento Sísmico
ZHAO, YAN, et al. (2008) apresentam o Distributed Execution Control
Framework (DECF), um sistema para apoiar o desenvolvimento de aplicações para
processamento sísmico em ambientes de computação distribuída, desenvolvida para a
Companhia Nacional de Petróleo da China. Assim como a proposta do presente
trabalho, o DECF permite o paralelismo de dados através da execução de um programa
sequencial, em vários NC, com dados de entrada distintos.
O DECF contém uma grande biblioteca de funcionalidades para geofísica que
o usuário pode utilizar para montar seu experimento. Ainda é possível que o usuário
adicione funcionalidades personalizadas, desde que elas contenham primitivas do DECF
no seu código fonte. O sistema conta com uma ferramenta gráfica que ajuda o
programador a gerar templates de código que facilitem a programação de novos
módulos compatíveis com o DECF
O artigo descreve as experiências de implementar a PKTM utilizando MPI e
DECF. O autor ressalta o ganho de produtividade acarretado pela possibilidade de
abstrair o experimento sísmico de questões relativas aos procedimentos de execução,
como implementação de paralelismo no código da solução, resiliência a falhas por
11
indisponibilidade de NC e manipulação de grande quantidade de dados entre as etapas
do processamento.
12
3. Chiron
O Chiron é um SGWfC paralelo projetado para executar workflows em
clusters computacionais. No Chiron, a modelagem de workflows é feita através da
álgebra para workflows científicos, que é derivada da álgebra relacional para banco de
dados (OGASAWARA, OLIVEIRA, et al., 2011). Para o Chiron, o conjunto de dados
de entrada do experimento é representado por uma ou mais relações. Usando da álgebra
de workflows proposta por OGASAWARA, OLIVEIRA, et al. (2011), o Chiron
identifica como os dados são estruturados e o que é esperado como entrada e saída de
cada etapa do workflow. Uma etapa do workflow é conhecida como atividade, sendo
responsável pela invocação de um programa ou serviço científico. Por meio da
modelagem do workflow científico por parte dos cientistas, o Chiron é capaz de realizar
otimizações algébricas e de adotar estratégias de execução eficientes. Este capítulo é
dedicado ao detalhamento das funcionalidades do Chiron.
O Chiron apresenta uma arquitetura centralizada baseada em um sistema de
troca de mensagens, no qual processos do motor de execução são executados ao longo
dos NC computacionais no ambiente de PAD. O sistema de troca de mensagens
adotado entre os NC do Chiron é uma implementação em Java da biblioteca MPI
(Message Passing Interface), conhecida como MPJ. Cada NC nesse sistema é
identificado por um número global (rank). Cada número global é responsável pela
inicialização de uma instância do Chiron.
13
Figura 1 – Representação da arquitetura do Chiron. Adaptado de OGASAWARA,
DIAS, et al. (2013).
Para apoiar a gerência de atividades, o Chiron funciona acoplado a um banco
de dados relacional a fim de registrar informações quanto à execução do workflow.
Apenas a instância principal do programa (NC 0) acessa o banco para leitura e
armazenamento desses dados conforme ilustra a Figura 1. Sendo assim, o Chiron
necessita da instalação do PostgreSQL e da máquina virtual Java (do inglês, Java
Virtual Machine - JVM). Diferentemente do NC 0, os outros NC são responsáveis por
receber novas tarefas pendentes (a serem executadas). Uma tarefa ou ativação consiste
pela álgebra de workflows em uma execução de uma atividade do workflow, que
consome um conjunto de tuplas específico.
Em relação à Figura 2, os NC de escalonamento são responsáveis por receber
as ativações do processador do workflow e distribuir para os processadores de ativação
disponíveis em um NC. Cada processador de ativação, dessa forma, executa o programa
ou serviço, consumindo dados existentes na relação de entrada e produzindo dados a
serem inseridos na relação de saída. Além disso, dados de proveniência são produzidos
ao processar as ativações, sendo os mesmos capturados e enviados para o processador
de workflow, que garantirá a persistência desses dados na base de proveniência.
14
Figura 2 - Arquitetura efetiva do Chiron. Adaptado de (OGASAWARA,
DIAS, et al., 2013).
3.1 Modelo de Representação: Álgebra de Workflows
Nos SGWfC que oferecem suporte ao paralelismo, o modelo de execução
costuma ser intrinsicamente relacionado às especificações do workflow. Além disso, em
geral, os SGWfC paralelos contam com poucos recursos que permitam criar estratégias
para otimizar a execução do workflow. Como solução para esta questão, o Chiron
possui uma álgebra de workflows própria, baseada na álgebra relacional de bancos de
dados.
Nos bancos de dados relacionais, a álgebra relacional é a principal ferramenta
para representar e otimizar consultas ao banco. O modo de representação de workflows
do Chiron é através de expressões algébricas, que permitem a modelagem dos
15
workflows, classificando as atividades que o compõem com operações da álgebra
relacional. As operações da álgebra relacional possuem semântica sobre a produção e o
consumo de dados, onde cada conjunto de dados de entrada tem semântica similar a
uma tupla nos bancos de dados relacionais. A representação de consultas em bancos de
dados utilizando operações algébricas permite navegar pelo espaço de soluções
encontrando consultas equivalentes que produzem o mesmo resultado, porém com
custos diferentes. A álgebra de workflows herda esta característica, permitindo gerar
workflows equivalentes que utilizam os recursos computacionais com maior eficiência.
A álgebra representa qualquer workflow classificando suas atividades através
de seis operações que caracterizam a razão entre o consumo e a produção de dados de
entrada e saída, isto é, caracterizam a razão entre o número de tuplas nas relações de
entrada e saída das atividades (Tabela 1). Os seis operadores que compõem a álgebra
relacional são: Map, SplitMap, Reduce, Filter, SRQuery e MRQuery. O comportamento
de cada um dos operadores algébricos é apresentado a seguir, do ponto de vista da
execução de uma ativação.
Map: Para cada tupla (conjunto de dados de entrada) na relação de entrada, é
gerada uma tupla na relação de saída.
SplitMap: Cada tupla na relação de entrada, a atividade produz um conjunto
de tuplas na relação de saída.
Reduce: Antes da invocação do programa, as tuplas do conjunto de entrada são
fragmentadas em subconjuntos de acordo com o valor de seus atributos. Cada
subconjunto resulta em uma ativação da atividade e gera um conjunto de tuplas
na relação de saída.
Filter: Na operação Filter, a atividade avalia cada tupla de entrada decidindo se
ela deve ser copiada para relação de saída ou não de acordo com alguma
avaliação de seus atributos. O esquema da relação de saída pode ser uma
projeção do esquema da relação de entrada. Em outras palavras, o esquema da
relação de saída não precisa conter todos os atributos da relação de entrada.
16
SRQuery: Esta operação é útil para a transformação ou filtragem de dados.
Esta operação consome uma relação de entrada, a processa através de uma
expressão da álgebra relacional, e produz uma relação de saída. Nos casos em
que as relações de entrada e saída tiverem o mesmo esquema, esta operação
pode ser entendida como um Filter.
MRQuery: Uma atividade regida pela operação MRQuery consome um
conjunto de relações, realiza uma expressão de álgebra relacional e produz
apenas uma relação de saída.
Tabela 1 - Operadores da álgebra de workflows. Adaptado de (OGASAWARA, DIAS,
et al., 2013).
Operador Tipo de Atividade
Operada Operandos Adicionais Resultados
Tuplas
Consumidas/
Produzidas
Map Programa Relação Relação 1:1
Split Map Programa Referência para Arquivo, Relação Relação 1:m
Reduce Programa Conjunto de atributos, Relação Relação n:1
Filter Programa Relação Relação 1 : (0-1)
SRQuery Expressão da álgebra
relacional Relação Relação m:n
MRQuery Expressão da álgebra
relacional Conjunto de Relações Relação m:n
3.2 Modelo de Execução de uma Ativação
A execução de uma atividade pelo Chiron é baseada no conceito de ativação.
Ativação é o nome dado ao conjunto que contém todas as informações necessárias para
a execução de uma atividade - etapa do workflow caracterizada por uma operação
algébrica - em qualquer NC. Após a execução a ativação, os dados de proveniência
coletados e armazenados na base de dados. Uma ativação contém as informações
relacionadas ao computador designado para executá-la, tuplas consumidas e produzidas,
17
status de execução, data e hora de início e término de execução, saída dos programas e
logs de erro.
Uma ativação é composta também de três etapas: instrumentação da entrada,
invocação do programa e extração da saída. Na instrumentação da entrada, o Chiron
extrai os parâmetros para execução do programa das tuplas de entrada. Na etapa de
invocação do programa, o programa associado à atividade é executado e monitorado. Na
etapa de extração de saída, o Chiron coleta dados da saída do programa executado na
etapa anterior e cria as tuplas de saída correspondentes na base de dados.
Figura 4 - Representação de uma expressão algébrica. (OGASAWARA,
OLIVEIRA, et al., 2011)
As ativações podem apresentar três estados: pronta, executando, finalizada.
Uma ativação recebe o estado de pronta quando todos os dados de entrada necessários
para sua execução estão disponíveis e a mesma está apenas aguardando a distribuição
para algum NC. O estado executando é dado quando a atividade está em um núcleo
realizando alguma das três etapas da execução (instrumentação, invocação ou extração).
Quando a execução da ativação termina e os dados de proveniência são extraídos, seu
estado é alterado para finalizada.
18
3.3 Modelo de Proveniência
O modelo de dados de proveniência do Chiron, PROV-Wf (COSTA, SILVA,
et al., 2013), foi construído com base nas recomendações do W3C PROV (MOREAU,
MISSIER, et al., 2011). Os elementos mais relevantes do PROV-Wf (Figura 4) são
classificados conforme os tipos abstratos do modelo de dados PROV: atividade, agente
e entidade. O cientista representa a pessoa que executa um workflow utilizando um NC
(Machine). Um workflow é executado a partir de um computador e é composto por
várias atividades (WActivity). Por sua vez, as atividades executam programas em NC
com uma configuração determinada. A invocação de um programa no workflow usa um
conjunto de parâmetros que pode ser visto como um conjunto de valores (fields). O
conjunto de tuplas associadas referente aos dados consumidos e produzidos pelas
atividades é organizado como uma relação. A entidade RelationSchema expressa os
vínculos entre as relações e as atividades.
Figura 5 - Modelo de dados do Prov-WF
19
O suporte à proveniência do Chiron permite consultar a base de proveniência
durante a execução do experimento. Em geral, os outros SGWfC permitem consultas à
proveniência apenas para workflows finalizados, pois armazenam os dados de
proveniência em arquivos temporários de log e ao final da execução do workflow, este
log é mapeado para a base de proveniência.
Esta característica do Chiron permite o monitoramento eficiente do
experimento através de consultas à base de proveniência durante a execução do
experimento. O cientista pode saber, por exemplo, quais atividades já foram executadas
e a sua duração, ou identificar se houve erro na execução de alguma atividade.
3.4 Estratégias de Escalonamento
Entende-se por escalonamento de workflows o mapeamento de todas as
ativações que compõem o workflow para os recursos computacionais disponíveis no
ambiente de PAD (SOUSA, 2014). A estratégia para escolha do escalonamento
adequado deve considerar as características do ambiente de PAD e permitir o uso mais
eficiente dos recursos computacionais. Também é desejável que a estratégia de
escalonamento seja tolerante a falhas, isto é, que seja capaz de permitir o
prosseguimento do experimento, caso algum NC falhe (COSTA, DE OLIVEIRA, et al.,
2012).
As estratégias de escalonamento podem ser estáticas ou dinâmicas. As
estratégias estáticas mapeiam todas as ativações do workflow para as unidades de
processamento no início da execução do workflow e não permite alterações ao longo da
execução. Nas estratégias de escalonamento dinâmico, o mapeamento das ativações é
feito em tempo de execução, de acordo com o progresso da execução do workflow.
Além disto, a estratégia dinâmica permite o balanceamento de cargas, importante,
20
sobretudo, por que a diferença de tempo de processamento entre duas ativações pode ser
muito grande e por que em ambientes computacionais heterogêneos, o tempo de
execução de uma mesma ativação pode variar muito entre os NC alocados, devido a
diferenças nas configurações dos NC.
A desvantagem do escalonamento dinâmico em relação ao estático é a
necessidade de comunicação mais intensa. Como as estratégias estáticas mapeiam as
ativações no início da execução, a troca de mensagens sobre instruções para execução
também acontece no início da execução. Na estratégia dinâmica, o NC mestre necessita
se comunicar com os outros NC para enviar novos pedidos de execução de ativações.
Assim, se a comunicação de rede for um gargalo ou não for confiável, o escalonamento
estático acaba sendo mais seguro, pois evitaria ociosidade por falta de comunicação e
sobrecargas na rede. Uma avaliação sobre a efetividade das estratégias em ambiente
específicos pode ser feita através de consultas à base de proveniência. Ao executar o
experimento, o Chiron coleta dados de proveniência que permitem avaliar desempenho,
ociosidade e ocorrência de erros na distribuição de tarefas.
As estratégias de escalonamento do Chiron consideram as dependências de
dados e de controle definidas na modelagem do workflow. O escalonamento deve
definir o número de NC máximo alocado levando em conta as características do
workflow. O número de NC não deve ser maior que o número de ativações que pode ser
executado simultaneamente, caso contrário, parte dos NC ficará ociosa durante a
execução do experimento (FOSTER, ZHAO, et al., 2008).
Para o Chiron, o menor grão de paralelismo é uma ativação, em outras
palavras, a menor tarefa que uma unidade de execução realiza é uma ativação. As
possibilidades de implementar paralelismo incluem considerar como menor unidade de
execução núcleo (core) do processador ou NC do ambiente de PAD.
21
No primeiro caso, o Chiron invoca uma ativação em cada núcleo disponível,
assim cada NC de processamento executa, simultaneamente, um número de ativações
igual ao número total de cores dos processadores que possui. No segundo, cada NC
recebe apenas uma ativação e o controle dos recursos de processamento intra-nó fica a
cargo da aplicação. Este recurso permite que o SGWfC seja usado em workflows que
incluam execução de programas que já contenham implementação de paralelismo como
diretivas de paralelismo OpenMP. Para informar ao Chiron que o controle do
paralelismo intra-nó deve ser deixado a cargo do programa associado à atividade, deve-
se ativar o atributo constrained. Já o primeiro caso, adequado para atividades onde o
programa invocado é completamente sequencial, pode ser implementado mantendo o
atributo constrained desativado, o que é configuração padrão do Chiron.
3.5 Modelagem de Workflows
No Chiron, os workflows são descritos através de arquivos XML que contém a
representação do workflow como grafo direcionado acíclico. O arquivo contém
especificações sobre atividades que compõem o workflow, explicitando
obrigatoriamente o operador algébrico, o programa a ser executados, assim como as
relações de entrada e saída. A dependência de dados, também obrigatória, é descrita
através do atributo dependency que informa qual relação precisa estar populada para que
a atividade seja executada. Implicitamente, sabe-se que a atividade que popula a relação
explicitada em dependency precisa ter sido executada.
Os atributos das relações envolvidas são descritos quanto ao seu tipo e sua
presença nas relações de entrada e saída. Os tipos de atributo possíveis incluem
numérico, textual e referência a arquivos. Além da especificação das atividades, o
arquivo contém informações como diretório do conjunto de dados de entrada do
22
workflow, diretório de execução, especificações sobre o ambiente de execução e acesso
à base de dados.
23
4. Migração Reversa no Tempo
As indústrias de óleo e gás investigam através de diversos métodos as
propriedades físicas do interior da terra com o propósito de aumentar as chances de
sucesso e redução de riscos na extração de hidrocarbonetos. O método sísmico, o mais
utilizado para este fim, se baseia na propagação de ondas sísmicas para delinear as
estruturas e propriedades geológicas no interior da Terra.
No método sísmico a aquisição de dados é realizada utilizando fontes artificiais
para gerar um pulso de energia mecânica - chamado de tiro (em inglês, shot) - cuja
frente de onda percorre o interior da terra e, ao alcançar interfaces entre camadas
geológicas, gera ondas refletidas que retornam a superfície e são captadas por sensores.
Associando os dados captados pelos sensores, que representam a amplitude das ondas
sísmicas refletidas, com o tempo decorrido entre o momento do tiro e a subsequente
captação da onda são construídos os sismogramas. Estes últimos, por sua vez,
constituem uma parcela considerável dos dados de entrada do processo de migração
sísmica.
Na aquisição de dados sísmicos terrestres (onshore), as ondas sísmicas são
geradas por explosivos ou caminhões vibradores chamados Vibroseis e os sensores que
captam as ondas refletidas são chamados de geofones. Quando o procedimento é
realizado no mar (offshore), a fonte geradora de ondas sísmicas é um canhão de ar
comprimido conhecido como airgun. Os sensores, neste caso hidrofones, ficam ligados
a um navio por meio de cabos alinhados paralelamente à direção de deslocamento em
uma configuração denominada streamer (Figura 6) que, por sua vez, é uma das mais
utilizadas em aquisições marítimas.
24
Figura 6 - Representação da aquisição sísmica marítima. (1) Fonte sísmica, (2)
Representação de uma reflexão na estrutura geológica, (3) Streamers, (4) Navio
sísmico. Adaptado de www.sercel.com/about/what-is-geophysics.aspx
Após a aquisição dos dados sísmicos a migração surge como uma etapa natural
na sequência de processamento. Migração é o procedimento de geração de uma imagem
precisa das camadas geológicas a partir das ondas captadas na aquisição sísmica.
Existem várias técnicas de migração sísmica, das quais Kirchhoff, Phase-Shift (PS),
Phase-Shift Plus Interpolation (PSPI) e a Migração Reversa no Tempo (RTM) são as
mais comuns. As aplicações de migração adotadas neste trabalho utilizam a técnica
RTM, pois é uma solução que atualmente está em destaque por ser bem sucedida
quando aplicada a modelos anisotrópicos e geologicamente complexos (ZHANG e
YAO, 2013), (VIRIEUX, 1984), (LEVANDER, 1988). Em consonância com os
objetivos aqui propostos, a migração RTM é, também, foco de extensas discussões no
âmbito computacional devido ao seu alto custo de processamento.
25
No processo de experimentação de algoritmos e técnicas geofísicas, é comum o
cientista precisar gerar dados sintéticos. A modelagem sísmica é o processo capaz de
gerar sismogramas sintéticos a partir de um modelo físico-matemático que simula os
fenômenos sísmicos envolvidos. Além disso, deve-se ressaltar que a modelagem
desempenha função preponderante para a migração, pois contém o stencil da equação da
onda que efetivamente propaga o campo de ondas e constitui o cerne do algoritmo de
migração.
A coerência da modelagem sísmica em relação aos fenômenos sísmicos
simulados é determinada pela formulação matemática da equação da onda empregada.
Dependendo da formulação, a modelagem pode contemplar desde fenômenos
puramente acústicos isotrópicos até complexos fenômenos visco-elásticos, além dos
anisotrópicos e elásticos (CLAPP, FU, et al., 2010). Embora a natureza do algoritmo
continue a mesma, a escolha da equação da onda tem consequência direta sobre as
propriedades geológicas consideradas, sobre a precisão dos resultados e sobre o custo
computacional. Neste trabalho, foi implementada a formulação acústica isotrópica 3D
da equação completa da onda, conforme a Equação 1, onde P(x,y,z,t) é o campo de
pressão da onda, x, y e z são as coordenadas espaciais, t é a coordenada temporal,
C(x,y,z) é a velocidade de propagação no meio e f(t) é o termo fonte.
𝝏𝟐𝑷(𝒙, 𝒚, 𝒛, 𝒕)
𝝏𝒙𝟐+
𝝏𝟐𝑷(𝒙, 𝒚, 𝒛, 𝒕)
𝝏𝒚𝟐+
𝝏𝟐𝑷(𝒙, 𝒚, 𝒛, 𝒕)
𝝏𝒛𝟐=
𝟏
𝑪(𝒙, 𝒚, 𝒛)𝟐
𝝏𝟐𝑷(𝒙, 𝒚, 𝒛, 𝒕)
𝝏𝒕𝟐+ 𝒇(𝒕)
Equação 1 - formulação acústica isotrópica da equação completa da onda
Com respeito à aplicação de modelagem, a abordagem mais comum consiste
em propagar o campo a partir da fonte sísmica adotando uma marcha de tempo explícita
26
(DABLAIN, 1986), cuja equação da onda é aproximada por séries de Taylor truncadas e
discretizadas por meio do método de Diferenças Finitas. Para cada passo de tempo é
realizada a computação do stencil a fim de determinar a energia (amplitude) do campo
de ondas em cada elemento do domínio espacial discretizado. Geralmente, as derivadas
temporais presentes na equação da onda são aproximadas por discretizações de segunda
ordem, enquanto que as derivadas espaciais são aproximações de ordens mais altas. Ou
seja, a energia em um determinado ponto do domínio espacial é calculada a partir dos
valores de amplitude nos pontos adjacentes e de seus próprios valores em passos de
tempo anteriores.
Já a aplicação de migração consiste basicamente em computar duas
modelagens, uma da perspectiva da fonte (forward, Figura 6) e outra da perspectiva dos
receptores (backward, Figura 7). Na forward o campo de ondas é propagado a partir da
fonte no tempo t = 0 até o momento t = time_steps em que os receptores param de
captar, criando um campo 4D em função do espaço e do tempo Pf(x, y, z, t).
Simultaneamente, na propagação backward, os sismogramas provenientes da aquisição
sísmica são inseridos na posição dos receptores a partir do tempo t = time_steps gerando
outro campo de ondas 4D Pr(x, y, z, t) que é computado até t = 0.
for t = 1 to time_steps
for x=2 to nx-1
for x=2 to nx-1
for x=2 to nx-1
Pf(x,y,z,t) = stencil (x,y,z,t)
Figura 7 - Pseudocódigo: Forward propagation
27
for t = time_steps to 1
for x=2 to nx-1
for x=2 to nx-1
for x=2 to nx-1
Pr(x,y,z,t) = stencil (x,y,z,t)
Imagem (x,y,z) = Pf(x,y,z,t)*Pr(x,y,z,t)
Figura 8 - Pseudocódigo: Backward propagation
for tiro = 1 to S
forward(Pf)
backward(Pr)
Empilhar_tiros
Figura 9 - Pseudocódigo: Migração Reversa no Tempo
A imagem final do processo de migração é proveniente da aplicação de uma
determinada condição de imagem, ou correlação, entre os dois campos. No caso deste
trabalho, a condição de imagem adotada foi a de correlação cruzada (Equação 5), na
qual a frente de onda dos campos Pf(x, y, z, t) e Pr(x, y, z, t) são correlacionadas para
todos os intervalos de tempo (CLAPP, FU, et al., 2010). Quando as duas frentes de
onda interagem construtivamente nas mesmas coordenadas espaço-temporais,
consideramos que existe objeto refletor (camada) naquela região espacial.
𝐼𝑚𝑎𝑔𝑒𝑚(𝑥, 𝑦, 𝑧) = ∑ ∑ 𝑃𝑓(𝑔, 𝑥, 𝑦, 𝑧, 𝑦)𝑃𝑟(x, y, z, t)
Equação 2 – Condição de imagem correlação cruzada.
Tanto na aplicação de modelagem quanto na de migração, os inputs são
arquivos binários que contêm as propriedades geofísicas da região a ser representada
por uma imagem, além dos parâmetros de execução da aplicação - como as dimensões
28
da malha, número de passos de tempo, parâmetros de otimização computacional,
caminhos de arquivos e diretórios, entre outros. Por fim, o algoritmo da migração exige
que os sismogramas provenientes da aquisição sísmica também sejam dados como
entrada.
O volume dos dados de entrada dessas aplicações varia em função das
dimensões do domínio (2D ou 3D) e da formulação matemática empregada. As saídas
(outputs) da aplicação de modelagem sísmica são arquivos binários que, dependendo da
finalidade, podem representar sismogramas sintéticos, matrizes de tempo de trânsito ou
a própria propagação do campo de ondas. A saída esperada da migração é um arquivo
contendo a seção migrada (ou imagem migrada) que, a priori, contém informações
visuais sobre o posicionamento das camadas geológicas.
4.1 Aspectos Computacionais
No segmento de óleo e gás o imageamento sísmico está na vanguarda do PAD,
posto que, potencialmente, exaure os recursos de processamento disponíveis nos
robustos clusters modernos. Particularmente, no tocante ao custo computacional da
migração RTM, a computação do stencil é responsável pela maior parte do tempo de
processamento e, por isto, é alvo das principais ações de otimização.
A complexidade computacional da modelagem pode ser descrita por O
(time_steps*shots*x*z) no caso bidimensional, e por O (time_steps*shots*x*y*z), no
caso tridimensional - onde x, y e z representam as dimensões espaciais do domínio,
time_steps é o número total de passos de tempo e shots é o número total de tiros
processados. Devido à sua baixa intensidade aritmética e à alta taxa de transferência de
dados, o algoritmo de modelagem sísmica é classificado como memory-bound, ou seja,
o custo de acesso à memória se sobrepõe ao custo de processamento. Essa característica
29
exige o emprego de arquiteturas com alta taxa de transferência de dados entre a
hierarquia de memória e o processador, bem como, a implementação de técnicas de
PAD que otimizem uso de dados.
Dentro do algoritmo de modelagem sísmica, o stencil da equação da onda é a
tarefa que exige maior esforço de processamento. Essa região do código está localizada
sob uma sequência de loops aninhados (como mostrado na Figura 9), cujas
características são determinantes para o desempenho do algoritmo. Dessa sequência
aninhada, o loop temporal é o único que não é passível de paralelização devido à
dependência entre execuções subsequentes. Os demais podem ser executados de
maneira concorrente, porém, sob perspectivas diferentes de paralelização.
for s = 1 to shots(MPI)
for t = 1 to time_steps
for x=2 to nx-1
for y=2 to ny-1
for z=2 to nz-1(OpenMP)
Pf(x,y,z,t) = stencil (x,y,z,t)
Figura 10 - Pseudocódigo: núcleo da aplicação Modelagem RTM
A paralelização do loop de tiros (loop mais externo) com MPI é conveniente,
pois não há dependência ou necessidade de sincronia entre a execução de tiros
subsequentes. Essa paralelização pode ser efetuada com alta escalabilidade em um
ambiente de memória distribuída, tipicamente atribuindo a execução de um tiro por NC.
Já os loops que iteram sobre o domínio espacial (x,y,z) apresentam
dependência de dados, demandando a paralelização em um ambiente de memória
compartilhada. No caso aqui discutido, diretivas de OpenMP são utilizadas para
distribuir a carga de trabalho do loop espacial mais externo entre os núcleos de
processamento existentes dentro de um NC.
30
A eficiência dessa estratégia é dependente da arquitetura intra-nó, demandando
a realização de análises de desempenho a fim de estabelecer a melhor configuração de
uso dos recursos disponíveis. Tal análise é apresentada no Capítulo 6. O
desenvolvimento do workflow da Modelagem Sísmica foi realizado a partir da
aplicação descrita acima, em duas etapas de acordo com as adaptações necessárias,
conforme detalhado no capítulo 5.
31
5. Modelagem das Atividades do Workflow
Este capítulo descreve a modelagem dos workflows desenvolvidos para o
experimento de modelagem RTM Isotrópica, bem como, o processo de adaptações
dessa aplicação ao SGWfC. Com intuito de evitar eventuais enganos de interpretação, é
importante ressaltar que há, neste trabalho, dois processos de modelagem
completamente distintos entre si. Sendo assim, os termos “modelagem sísmica” e
“modelagem de workflows” não devem ser confundidos.
A modelagem sísmica está relacionada à propagação do campo de ondas,
conforme definido no capítulo 4. Já a modelagem de workflows se refere à configuração
das atividades, considerando as dependências de dados e as relações de entrada e saída.
Ou seja, a modelagem de workflows se refere a integrar os programas que compõem o
experimento por meio da definição das atividades e das suas dependências de acordo
com as especificações do SGWfC.
5.1 Workflow Modelagem RTM
O Chiron não é compatível com execução em vários NC usando a tecnologia
MPI e as iterações do loop de tiros da aplicação original são independentes entre si, isto
é, a iteração i não depende da iteração i-1. Assim, para a primeira versão do workflow,
alteramos a aplicação de maneira a remover o loop de tiros (e consequentemente a
presença do MPI). Com isto, a nova aplicação é capaz de processar apenas um tiro por
invocação. Desta maneira, o Chiron pode invocar o processamento de um tiro por NC a
cada ativação.
32
for t = 1 to time_steps
for x=2 to nx-1
for x=2 to nx-1
for x=2 to nx-1 (OpenMP)
Pf(x,y,z,t) = stencil (x,y,z,t)
Figura 11 – Pseudocódigo: atividade Modelagem RTM Versão 1
Para fazer a interface entre o arquivo de configuração da Modelagem RTM e o
novo executável, isto é, fazer com que o workflow execute uma sequência de tiros, é
necessário gerar as invocações correspondentes ao conjunto de tiros. Para isto, foi
adicionada uma atividade no workflow antes da modelagem: atividade de pré-
processamento, caracterizada pelo operador algébrico de SPLIT_MAP. Sua entrada é
especificada por um arquivo no formato TXT, que contém a configuração do
experimento, incluindo o intervalo de tiros que deve ser processado. Sua saída é uma
relação cujas tuplas representam cada um dos tiros a serem processados. Cada tupla
desse arquivo consiste em uma ativação da atividade que realiza a modelagem (Figura
12).
Modeling
Pre-processing
Figura 11 - Workflow Modelagem RTM
33
A atividade Modelagem RTM consome o arquivo de configuração do
experimento, que contém os parâmetros geofísicos, o binário que contém o modelo de
velocidades e produz um sismograma. Como a aplicação invocada por esta atividade
contém diretivas de paralelismo, a atividade está configurada com o atributo
constrained ativado como verdadeiro. Com esta configuração, o Chiron invoca apenas
uma ativação por NC, assim, todos os recursos de processamento do NC ficam
disponíveis para uma única instância da aplicação.
A diferença da versão 2, em relação à versão 1, é a remoção das diretivas de
paralelismo do código-fonte e a mudança na especificação da atividade. Como a
atividade é completamente sequencial, o Chiron pode manipular todo paralelismo.
Assim, o número de ativações por NC é especificado no atributo cores na configuração
do workflow.
5.2 Workflow Migração Sísmica
A aplicação original (Figura 13) tem como entradas arquivos binários que
contém informações sobre propriedades geofísicas da região analisada, e um arquivo de
texto com dados que determinam a configuração do experimento como parâmetros
relativos à modelagem do problema, como espessura da malha e número de passos de
tempo, parâmetros de PAD, caminhos de arquivos, diretórios, etc. A saída da aplicação
é um conjunto de três arquivos binários que representam três imagens migradas, com
diferentes condições de imagem: fonte, receptor e correlação.
As estratégias de paralelismo para esta aplicação segue os mesmos princípios
empregados para a modelagem sísmica. A etapa Empilhar_Tiros seria uma candidata a
paralelismo de dados, visto que itera novamente sobre todos os tiros. Entretanto, como é
34
uma rotina computacionalmente menos custosa que as etapas anteriores (da ordem de
um milésimo de uma ativação da atividade migração), paralelizá-la não traria benefícios
significativos.
for s=1 to shots (MPI)
forward(s) (OpenMP)
backward(Pf,Pr) (OpenMP)
Empilhar_tiros
Figura 13 - Pseudocódigo: Migração Reversa no Tempo
O Chiron é capaz de manipular o paralelismo da aplicação através da execução
de múltiplas instâncias independentes da mesma aplicação com diferentes tuplas de
entrada. Na corrente aplicação, o laço de tiros, paralelizado com MPI, realiza esta
função. Neste contexto, cada NC disponível processa uma sequência de tiros.
Na implementação da versão 1 do workflow Migração RTM, o Chiron fica
responsável por distribuir o processamento dos tiros entre os NC disponíveis. Para isto
ocorrer, foi preciso alterar o fluxo do programa original, retirando o loop que controlava
a distribuição dos tiros. Na nova versão da aplicação, apenas um tiro é processado,
como foi feito na aplicação de modelagem. Surgem, naturalmente, novas atividades do
workflow, conforme mostra a Figura 14.
A atividade de pré-processamento gera, a partir dos parâmetros de entrada do
workflow, os dados que permitem ao Chiron realizar a execução de todos os tiros. Esta
atividade recebe como entrada o arquivo de configuração do experimento. Essa
atividade também responsável por extrair os parâmetros de execução do experimento, e
produz um conjunto de tuplas representando os dados de entrada da atividade seguinte,
que processa um tiro por ativação.
35
A segunda atividade processa um tiro por vez, ou seja, cada tiro é representado
por uma tupla de saída da atividade anterior e gera uma ativação nesta atividade. As
entradas desta atividade são o identificador do tiro que está sendo processado (um
número inteiro) e as referências para arquivos binários e o sismograma relativo ao
mesmo tiro. A saída desta atividade é um arquivo binário que representa a contribuição
de imagem do tiro processado. A especificação desta atividade contém o atributo
ativado como verdadeiro, para indicar que a gerência do paralelismo intra-nó deve ser
deixado a cargo da aplicação, neste caso, paralelizada com OpenMP.
Figura 14 - Workflow Migração RTM
A atividade de empilhamento é responsável por reunir a contribuição de todos
os tiros em um único arquivo que contenha as informações de imagem de todo o
domínio. Esta atividade consome os arquivos binários produzidos na atividade anterior
36
e gera apenas um arquivo binário. A saída desta atividade contém as mesmas
informações que a saída da aplicação original.
Na segunda versão, o código do programa de migração foi alterado, retirando
as diretivas de paralelismo OpenMP e a especificação da atividade não contém mais o
atributo constrained ativado como verdadeiro. Nesta versão, todo o workflow executa
de maneira sequencial, assim, é possível que o Chiron controle todo o paralelismo de
maneira eficiente.
5.3 Pós-processamento
A análise de resultados realizada após a execução de um experimento RTM é
realizada, inclusive, através da visualização da imagem migrada. Para visualização de
arquivos binários, é necessário o uso de ferramentas como o Seismic Un*x Ximage que
permite visualizar em tela ou o Seismic Un*x PSimage que permite exportar o resultado
como uma imagem tipo PostScript. Como este procedimento é uma ação natural, quase
obrigatória, que segue o processamento RTM, adicionamos ao workflow a geração da
imagem PostScript (Figura 15).
Assim o cientista pode visualizar seus resultados de maneira mais imediata. No
caso de um processamento remoto, ou na nuvem, o cientista não precisa transferir o
arquivo binário, que é muito pesado. Em vez disso, pode transferir o arquivo PostScript
que é muito mais leve.
37
Figura 15 – Adição da atividade de pós-processamento
38
6. Análise Experimental
Neste capítulo são apresentados os testes de validação e comparativos de
desempenho entre os workflows desenvolvidos e as aplicações originais paralelizadas
com OpenMP e MPI. Foram realizados vários testes com intuito de avaliar a influência
de parâmetros inerentes ao SGWfC, assim como, o efeito da seleção de diferentes
configurações de paralelismo na execução de atividades.
As análises experimentais descritas foram efetuadas no cluster Uranus que
pertence ao Núcleo Avançado de Computação de Alto Desempenho (NACAD -
COPPE/UFRJ). Abaixo são listadas as principais características de sua arquitetura, cuja
representação esquemática é mostrada na Figura 16.
Nós: 32 dual socket Intel Xeon X5650 (Westmere) e 32 dual socket Intel Xeon
X5355 (Clovertown);
Memória: 1.28 TBytes RAM (distribuída);
Armazenamento em disco: SGI InfiniteStorage NAS (72 TBytes);
Rede: Infiniband QDR, DDR e Gigabit;
Sistema operacional: Suse Linux Enterprise Server (SLES) + SGI Performance
Suite;
Compiladores: Intel e GNU (Fortran-90 e C/C++) com suporte OpenMP;
MPI: MPT (SGI® Message Passing Toolkit), MVAPICH2 e OpenMPI;
Figura 16 - Representação esquemática da arquitetura dual socket de um
NC de processamento do Cluster Uranus
39
6.1 Configuração dos Experimentos
A aplicação de modelagem sísmica foi executada utilizando o benchmark
SEG/EAGE Salt C3, que representa uma estrutura salina típica da Costa do Golfo dos
Estados Unidos com razoável complexidade estrutural. Este dado sintético
tridimensional foi concebido com a finalidade de testar algoritmos de imageamento
sísmico, particularmente em regiões de sub-sal. A Figura 16 ilustra o modelo de
velocidades do benchmark, cujas dimensões do domínio são 4250 metros na direção Z e
15000 metros nas direções X e Y. O conjunto de dados inclui os sismogramas referentes
aos 2400 pontos de tiro disparados na superfície do modelo.
Figura 17 - Benchmark SEG/EAGE Salt C3. Adaptado de
http://utam.gg.utah.edu/tomo06/06_ann/HTML/yibo_inter_single
A fim de determinar a melhor configuração de uso dos recursos intra-nó no
cluster Uranus, utilizando 8 NC com processadores Intel Xeon X5355. Cada NC do
cluster Uranus é composto por dois processadores (dual socket). Por sua vez, cada um
40
possui quatro núcleos (C0, C1, C2, C3), totalizando oito unidades de processamento
disponíveis por NC. Foram efetuadas várias execuções da atividade de modelagem
sísmica alterando os parâmetros de OpenMP e MPI, tanto para a versão original quanto
para a versão adaptada ao Chiron. Ambas as tabelas contêm os resultados de speedup
calculados em relação à execução sequencial.
A Tabela 2 discrimina as configurações empregando paralelismo no nível do
loop de tiros na versão do workflow que não possui OpenMP. Uma vez que a biblioteca
MPI e o SGWfC são empregados na paralelização do loop de tiros, vale frisar que o
número de processos MPI ou ativações do Chiron executados simultaneamente são
equivalentes à quantidade de tiros executados em paralelo. Ou seja, na Tabela 2, o
número de cores efetivamente utilizados em cada configuração é igual ao número de
tiros processados.
Tabela 2 – Desempenho da Modelagem Sísmica
Número de Tiros
Speedup
MPI Chiron
1 1.0 0,9
2 1.9 1,9
4 3.5 3,6
8 6,1 5,9
A Tabela 3 é referente à utilização conjunta de ambos os níveis de paralelismo.
Neste experimento, threads de OpenMP estão aninhadas abaixo de cada processo
MPI/ativação e são dedicadas à paralelização das tarefas dentro de cada tiro. Neste
experimento, em todas as configurações, todos os núcleos disponíveis no NC foram
utilizados.
41
Tabela 3 - Desempenho da Modelagem Sísmica paralelizada com MPI e OpenMP
Número de Tiros Número de threads
OpenMP
Speedup
MPI Chiron
1 8 5,4 3,3
2 4 6,6 5,4
4 2 6,4 6,4
8 1 5,9 5,9
Vale notar que, nos testes contemplados na Tabela 3, a configuração do
workflow informava ao Chiron que a aplicação não continha paralelismo. Isto é, a
especificação continha o atributo constrained desativado. Nesta configuração, a
quantidade de tiros processada foi controlada através do atributo cores, na configuração
do workflow. A maneira mais recomendada de se executar programas paralelizados com
o Chiron é ativar o atributo constrained e permitir que a aplicação gerencie os recursos
de processamento do NC.
Conforme observado nas tabelas, o melhor desempenho da aplicação original é
obtido executando dois processos de MPI - ou seja, dois tiros por NC – associando
quatro threads de OpenMP a cada processo. Esse fato se deve tanto a fatores da
arquitetura de processamento, quanto a características do algoritmo de modelagem
sísmica.
Do ponto de vista do algoritmo, a paralelização de um tiro dedicando todos os
oito núcleos de processamento às threads do OpenMP gera um speedup de 5,4
(conforme Tabela 3), cuja eficiência de 67% indica a baixa escalabilidade do algoritmo
42
nesta configuração de recursos. Por outro lado, o caso de maior speedup (6,6) é também
o mais eficiente (83%) entre todos as configurações testadas, indicando que a
“escalabilidade ótima” é alcançada quando todos os núcleos de um socket são dedicados
à execução de um único processo MPI. É importante ressaltar que a variação do tempo
de processamento entre as repetições de testes com a mesma configuração foi
desprezível.
Observando o resultado dos testes, nota-se que o melhor resultado na avaliação
do Chiron foi alcançado executando 4 tiros simultâneos com 2 threads OpenMP cada,
com um speedup de 6,4. E, no mesmo teste, o pior desempenho foi obtido executando
um tiro com 8 threads OpenMP. Ativando o atributo constrained na atividade de
modelagem sísmica, é executado necessariamente um tiro por NC, e o speedup
observado foi de 5,4, mesma escalabilidade vista na para um tiro sendo executado com
OpenMP e MPI nas mesmas configurações. De maneira geral, pode-se concluir que o
Chiron é capaz de paralelizar a modelagem sísmica com eficiência muito próxima à da
aplicação original.
6.2 Consultas à base de proveniência
Ao longo da realização de experimentos, os cientistas precisam monitorar a
execução das atividades e avaliar resultados parciais. Quando o experimento é realizado
em ambiente distribuído, esta tarefa se torna mais complexa. O Chiron permite acesso a
à proveniência durante a execução do experimento através de consultas. As consultas à
base de proveniência podem ser feitas através da interface gráfica do PostgreSQL, o
PgAdmin III.
43
Ao monitorar a execução dos testes realizados neste trabalho, foi necessário
executar consultas para obter dados de proveniência. Estão citadas abaixo algumas das
consultas que podem ser úteis ao usuário da aplicação.
Um workflow pode ser executado diversas vezes, com dados de entrada
diferentes. O cientista identifica cada uma destas variações através de um rótulo de
execução (tagexec, na base de proveniência). A consulta abaixo descreve a consulta
SQL que retorna quais as atividades que estão em execução além da identificação dos
respectivos workflows. Na base de dados, eworkflow.tag, representa o “nome” do
workflow e eactivity.status descreve o estado da atividade naquela instância do
workflow.
A consulta abaixo identifica e retorna a linha de comando invocada
(eactivation.commandline) para ativações que retornaram alguma mensagem de erro
(eactivation.terr).
SELECT DISTINCT eworkflow.tagexec, eworkflow.tag, eworkflow.ewkfid
from eworkflow join eactivity
on eactivity.status='RUNNING';
SELECT eworkflow.tag AS wftag, eworkflow.tagexec,
eactivity.tag as acttag, eactivation.terr,eactivation.exitstatus,
eactivation.commandline
FROM eactivation,eactivity,eworkflow
WHERE (eactivation.terr <> ' ' AND
eactivation.actid=eactivity.actid and eactivity.wkfid=eworkflow.ewkfid);
44
A consulta a seguir retorna a configuração de entrada para uma execução
específica, a partir de um rótulo de execução. Esta consulta pode ser particularmente útil
quando existem várias execuções em andamento e se deseja saber que dados de entrada
o workflow consumiu.
A consulta abaixo retorna os dados de entrada correspondentes ao dado arquivo
de saída.
As consultas mostradas podem ser facilitar o monitoramento do experimento no
contexto de múltiplas execuções, ou em ambiente de PAD pois facilitam o
monitoramento da execução e a gerência da geração e consumo de dados. É importante
SELECT DISTINCT conf_file,
FROM rtm_tti_2_seq_local.preprocessor_in
WHERE ewkfid IN(SELECT ewkfid FROM eworkflow
WHERE tagexec='rtm_tti_2_seq_local-m4');
SELECT DISTINCT
rtm_tti_2_seq_local.preprocessor_out.conf_file,
rtm_tti_2_seq_local.preprocessor_out.vel_model
FROM rtm_tti_2_seq_local.preprocessor_out
WHERE ewkfid
IN (select ewkfid FROM
rtm_tti_2_seq_local.rtm_postprocessing_out
WHERE png_file LIKE
'%/m4/postprocessing/2/mig_source.ps');
45
notar que as duas primeiras consultas podem ser reaproveitadas para extrair dados de
qualquer workflow executado sob o Chiron. As duas últimas consultas também podem
ser utilizadas desde que as referências que especificam o contexto do workflow sejam
substituídas. Por outro lado, na aplicação original de sísmica, obter os mesmos dados
seria uma tarefa mais trabalhosa e propensa a erros, visto que seria necessário acessar o
sistema de arquivos do cluster e analisar arquivos de log de execução.
46
7. Conclusão
Conforme foi visto nos capítulos anteriores, obter o melhor desempenho de
uma aplicação paralela exige, além de adição de diretivas de paralelismo no código-
fonte da aplicação, conhecimento sobre características da arquitetura dos processadores
e da infraestrutura computacional em que a aplicação será executada.
Os testes de desempenho mostram que a solução proposta é eficiente, no que
diz respeito ao uso dos recursos disponíveis. O Chiron foi capaz de alcançar bom
desempenho na execução de aplicações sequenciais em ambiente paralelo, mostrando
eficiência simular à da aplicação original.
Para a realização de experimentos em sísmica, é razoável supor que o uso de
SGWfC paralelos, como o Chiron, representa considerável ganho de produtividade,
dado que o cientista pode se concentrar nos objetivos do experimento em si e abstrair de
questões ligadas questões computacionais como paralelismo, tolerância a falhas.
Conforme foi dito, o imageamento sísmico exige grande quantidade de
recursos de PAD e muito tempo de processamento. Um experimento de sísmica pode
passar meses executando, o que maximiza a importância do bom uso de recursos e a
inviabilidade de esperar o término do experimento para visualizar os resultados. O
sistema de apoio à proveniência oferecido pelo Chiron se mostrou eficiente em permitir
acesso a resultados parciais e dados sobre a execução do workflow durante e após a
execução.
Em contrapartida, é necessário que o cientista tenha em mente certos conceitos
que permitam a modelagem adequada do workflow. Conforme visto neste trabalho, para
transformar um experimento de sísmica em workflow é preciso identificar a
cardinalidade da produção e consumo de arquivos em suas atividades, e sua relação com
47
operadores algébricos, e desenvolver extratores para extrair dados de proveniência da
saída dos programas. Pode ser necessário que o cientista busque oportunidades de
fragmentar suas aplicações originais em aplicações menores, para favorecer o
paralelismo de dados. A experiência deste trabalho, permitiu notar que modelar um
workflow se torna uma tarefa mais ágil à medida que se toma conhecimento das
particularidades do SGWfC.
48
Referências Bibliográficas
AALST, W. VAN DER, HEE, K. M. VAN, 2002, Workflow management models, methods, and systems. Cambridge, Mass., MIT Press.
AMBLER, S. W., 2002, Agile modeling: effective practices for eXtreme programming and the unified process. New York, J. Wiley.
BARGA, R. S., FAY, D., GUO, D., et al., 2008, "Efficient scheduling of scientific workflows in a high performance computing cluster". In: Challenges of Large Applications in Distributed Environments (CLADE), pp. 63–68, New York, NY, USA.
BERRIMAN, G. B., DEELMAN, E., GOOD, J., et al., 2007, "Generating Complex Astronomy Workflows", In: TAYLOR, I. J., DEELMAN, E., GANNON, D. B., et al. [eds.] (eds), Workflows for e-Science, London: Springer London, pp. 19–38.
BROWN, D. A., BRADY, P. R., DIETZ, A., et al., 2007, "A Case Study on the Use of Workflow Technologies for Scientific Analysis: Gravitational Wave Data Analysis", In: TAYLOR, I. J., DEELMAN, E., GANNON, D. B., et al. [eds.] (eds), Workflows for e-Science, London: Springer London, pp. 39–59.
BUX, M., LESER, U., 2013, "Parallelization in Scientific Workflow Management Systems", CoRR, v. abs/1303.7195
CALLAHAN, S. P., FREIRE, J., SANTOS, E., et al., 2006, "VisTrails: Visualization Meets Data Management". In: Proceedings of the 2006 ACM SIGMOD International Conference on Management of Data, pp. 745–747, New York, NY, USA.
CLAPP, R. G., FU, H., LINDTJORN, O., 2010, "Selecting the right hardware for reverse time migration", The Leading Edge, v. 29, n. 1 (Jan.), pp. 48–58.
COSTA, F., DE OLIVEIRA, D., OCAÑA, K. A. C. S., et al., 2012, "Enabling Re-executions of Parallel Scientific Workflows Using Runtime Provenance Data", In: GROTH, P., FREW, J. [eds.], HUTCHISON, D., KANADE, T., KITTLER, J., et al. (eds), Provenance and Annotation of Data and Processes, , chapter 7525, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 229–232.
COSTA, F., SILVA, V., DE OLIVEIRA, D., et al., 2013, "Capturing and Querying Workflow Runtime Provenance with PROV: A Practical Approach". In: Proceedings of the Joint EDBT/ICDT 2013 Workshops, pp. 282–289, New York, NY, USA.
DABLAIN, M. A., 1986, "The application of high‐order differencing to the scalar wave equation", GEOPHYSICS, v. 51, n. 1 (Jan.), pp. 54–66.
DEAN, J., GHEMAWAT, S., 2008, "MapReduce: simplified data processing on large clusters", Communications of the ACM, v. 51, n. 1 (Jan.), pp. 107.
DEELMAN, E., MEHTA, G., SINGH, G., et al., 2007, "Pegasus: Mapping Large-Scale Workflows to Distributed Resources", In: TAYLOR, I. J., DEELMAN, E.,
49
GANNON, D. B., et al. [eds.] (eds), Workflows for e-Science, London: Springer London, pp. 376–394.
DIAS, J., OGASAWARA, E., DE OLIVEIRA, D., et al., 2013, "Algebraic dataflows for big data analysis". , pp. 150–155
FOSTER, I., ZHAO, Y., RAICU, I., et al., 2008, "Cloud Computing and Grid Computing 360-Degree Compared". , pp. 1–10
FREIRE, J., KOOP, D., SANTOS, E., et al., 2008, "Provenance for Computational Tasks: A Survey", Computing in Science & Engineering, v. 10, n. 3 (May.), pp. 11–21.
GOECKS, J., NEKRUTENKO, A., TAYLOR, J., et al., 2010, "Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences", Genome Biology, v. 11, n. 8, pp. R86.
GUERRA, G., ROCHINHA, F., ELIAS, R., et al., 2009, "Scientific workflow management system applied to uncertainty quantification in large eddy simulation", Congresso Ibero Americano de Métodos Computacionais em Engenharia, pp. 1–13.
JACOB, J. C., KATZ, D. S., BERRIMAN, G. B., et al., 2009, "Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking", Int. J. Comput. Sci. Eng., v. 4, n. 2 (Jul.), pp. 73–87.
LEVANDER, A. R., 1988, "Fourth‐order finite‐difference P-SV seismograms", GEOPHYSICS, v. 53, n. 11 (Nov.), pp. 1425–1436.
LUDÄSCHER, B., ALTINTAS, I., BERKLEY, C., et al., 2006, "Scientific Workflow Management and the Kepler System: Research Articles", Concurr. Comput. : Pract. Exper., v. 18, n. 10 (Aug.), pp. 1039–1065.
MISSIER, P., SOILAND-REYES, S., OWEN, S., et al., 2010, "Taverna, Reloaded". In: Proceedings of the 22Nd International Conference on Scientific and Statistical Database Management, pp. 471–481, Berlin, Heidelberg.
MOREAU, L., MISSIER, P., BELHAJJAME, K., et al. The PROV Data Model and Abstract Syntax Notation., 2011 Disponível em: http://www.w3.org/TR/prov-dm/. Acesso em: 23 Feb 2014.
OCAÑA, K. A. C. S., DE OLIVEIRA, D., OGASAWARA, E., et al., 2011, "SciPhy: A Cloud-Based Workflow for Phylogenetic Analysis of Drug Targets in Protozoan Genomes", In: NORBERTO DE SOUZA, O., TELLES, G. P., PALAKAL, M. [eds.], HUTCHISON, D., KANADE, T., KITTLER, J., et al. (eds), Advances in Bioinformatics and Computational Biology, , chapter 6832, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 66–70.
OGASAWARA, E., DIAS, J., SILVA, V., et al., 2013, "Chiron: a parallel engine for algebraic scientific workflows: CHIRON: A PARALLEL ENGINE FOR ALGEBRAIC SCIENTIFIC WORKFLOWS", Concurrency and Computation: Practice and Experience, v. 25, n. 16 (Nov.), pp. 2327–2341.
50
OGASAWARA, E. S., OLIVEIRA, D. DE, VALDURIEZ, P., et al., 2011, "An Algebraic Approach for Data-Centric Scientific Workflows", PVLDB, v. 4, n. 12, pp. 1328–1339.
RIZVANDI, N. B., BOLOORI, A. J., KAMYABPOUR, N., et al., 2011, "MapReduce Implementation of Prestack Kirchhoff Time Migration (PKTM) on Seismic Data". , pp. 86–91
RODRIGUEZ, J. E., HANZICH, M., GUTIERREZ, N., et al., 2013, "Supporting Massive Parallelism in Seismic Processing".
DA SILVA, F. A. B., SENGER, H., 2009, "Improving scalability of Bag-of-Tasks applications running on master–slave platforms", Parallel Computing, v. 35, n. 2 (Feb.), pp. 57–71.
SOUSA, V. S., 2014, Uma Estratégia de Execução Paralela Adaptável de Workflows Científicos. Dissertação (mestrado), UFRJ/ COPPE/ Programa de Engenharia de Sistemas e Computação
STEVENS, R., MCENTIRE, R., GOBLE, C., et al., 2004, "myGrid and the drug discovery process", Drug Discovery Today: BIOSILICO, v. 2, n. 4 (Jul.), pp. 140–148.
VIRIEUX, J., 1984, "SH-wave propagation in heterogeneous media: Velocity‐stress
finite‐difference method", GEOPHYSICS, v. 49, n. 11 (Nov.), pp. 1933–1942.
WOZNIAK, J. M., ARMSTRONG, T. G., WILDE, M., et al., 2013, "Swift/T: Large-Scale Application Composition via Distributed-Memory Dataflow Processing". , pp. 95–102
ZHANG, J. H., YAO, Z. X., 2013, "Optimized finite-difference operator for broadband seismic wave modeling", GEOPHYSICS, v. 78, n. 1 (Jan.), pp. A13–A18.
ZHAO, C., YAN, H., SHI, X., et al., 2008, "DECF: A Coarse-Grained Data-Parallel Programming Framework for Seismic Processing". , pp. 454–460
![Workflow p10[1] Copy](https://img.document.onl/doc/110x75/5572141d497959fc0b93cd57/workflow-p101-copy.jpg)
