Avaliação de Desempenho de Análises de Ancoragem Molecular em Nuvens de Computadores por meio de Workflow Científicos

Avaliação de Desempenho de Análises de Ancoragem Molecular em Nuvens de Computadores por meio de Workflow Científicos Silvia Benza Bareiro 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 Engenheira. Orientadores: Marta Lima de Queirós Mattoso Kary Ann del Carmen Soriano Ocaña Rio de Janeiro Dezembro de 2013

AVALIAÇÃO DE DESEMPENHO DE ANÁLISES DE ANCORAGEM MOLECULAR EM NUVENS DE COMPUTADORES POR MEIO DE WORKFLOWS CIENTÍFICOS Silvia Benza Bareiro 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: Profa. Marta Lima de Queirós Mattoso, D.Sc. Profa. Kary Ann del Carmen Soriano Ocaña, D.Sc Prof. Daniel Cardoso Moraes de Oliveira, D.Sc. Prof. Alexandre de Assis Bento Lima, D.Sc. RIO DE JANEIRO, RJ BRASIL Dezembro de 2013

Silvia Benza Bareiro Avaliação de Desempenho de Análises de Ancoragem Molecular em Nuvens de Computadores por meio de Workflow Científicos/Silvia Benza Bareiro. Rio de Janeiro: UFRJ/ Escola Politécnica, 2013. VIII, 58 p.: il.; 29,7 cm. Orientadores: Marta Lima de Queirós Mattoso e Kary Ann del Carmen Soriano Ocaña Projeto de Graduação UFRJ/ Escola Politécnica/ Curso de Engenharia de Computação e Informação, 2014. Referências Bibliográficas: p63 1. Workflows Científicos 2. Computação em Nuvem 3. Ancoragem Molecular I. Mattoso, Marta Lima de Queirós Mattoso et al. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Curso de Engenharia de Computação e Informação. III. Título. 1

2

AGRADECIMENTOS Após uma longa jornada cheia de experiências tanto boas como difíceis, chega ao fim este ciclo. A quantidade de pessoas que fizeram isto possível é enorme, mas devo começar agradecendo à minha mãe e ao meu pai, sem eles nada disso teria acontecido. À minha mãe Carmen, meu norte, sempre ensinando e guiando meus passos para dar o melhor e apontar para as estrelas. Ao meu pai Francisco, minha base sólida, sempre dando forças para continuar junto com os conselhos certos para não decair. Aos meus irmãos, Francisco, Bruno, Alejandra e Martin, mesmo na distância nossos laços nunca se perderam, as nossas brincadeiras continuam as mesmas, como se tivéssemos 10 anos. Aos meus colegas de ECI, que se tornaram a minha família longe de casa, importando milagres e criando lemas como ECI não dorme, lidamos com o peso da faculdade com humor e amizade. Agradeço também aos meus professores, em especial à professora Marta Lima de Queirós Mattoso, minha orientadora, pelas excelentes aulas que inspiraram o tema deste projeto e por ter me dado a chance de trabalhar junto com ela. À professora Kary Ann del Carmen Soriano Ocaña, pela incansável ajuda, sempre me dando força e respondendo até as mais bobas perguntas de biologia. Muito obrigada! Aos meus amigos, por fazer do Rio um lugar incrível de morar, diminuindo a saudade que sinto da minha terra. Ao CERP-RIO e a todos os estudantes paraguaios. Que as nossas costumes de coração de mãe nunca terminem. Enfim, a todos os que me apoiaram e de alguma forma fizeram única esta experiência, de coração muito obrigada. 3

Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheira de Computação e Informação. Avaliação de Desempenho de Análises de Ancoragem Molecular em Nuvens de Computadores por meio de Workflows Científicos Silvia Benza Bareiro Dezembro/2013 Orientadores: Marta Lima de Queirós Mattoso Kary Ann del Carmen Soriano Ocaña Curso: Engenharia de Computação e Informação Um experimento científico é a associação sequencial de atividades controladas a partir da simulação de um fenômeno de interesse, com o fim de corroborar a aceitação ou rejeição de uma hipótese. O gerenciamento deste encadeamento não é trivial de ser realizado e pode ser apoiado por técnicas como a modelagem de workflows científicos e ferramentas como Sistemas de Gerência de Workflows Científicos (SGWfC). Grande parte dos experimentos em larga escala existentes, modelados como workflows, são computacionalmente intensivos e precisam ser executados em ambientes de processamento de alto desempenho (PAD). Workflows científicos aplicados a experimentos de bioinformática têm mostrado serem eficazes devido à organização e gerência do fluxo de atividades. Especialmente em experimentos de ancoragem molecular que precisam de ambientes PAD devido à exploração de um grande número de dados e parâmetros. Neste projeto, o objetivo é propor e avaliar uma infraestrutura computacional que dê apoio ao ciclo de vida do experimento de ancoragem molecular, que visa levantar hipóteses sobre candidatos a fármacos. Propomos a modelagem das análises in silico de ancoragem molecular como workflows científicos, gerenciados por SGWfC, executados e avaliados em ambientes de nuvens de computador. 4

Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of the requirements for the degree of Computer and Information Engineer. Performance Evaluation of Molecular Docking Analyses in Clouds using Scientific Workflows Silvia Benza Bareiro Dezembro/2013 Advisors: Marta Lima de Queirós Mattoso Kary Ann del Carmen Soriano Ocaña Major: Computer and Information Engineering A scientific experiment is a sequential association of controlled activities to obtain results from the simulation about a phenomenon of interest, in order to support the acceptance or rejection of a hypothesis. The management of this flow is not a trivial task to be performed and can be supported by scientific workflows modeling techniques and Scientific Workflows Management Systems (SWfMS) tools. Much of the existing large-scale experiments, modeled as workflows, are computationally intensive and need to be executed in high-performance computing (HPC) environments. Scientific workflows applied to bioinformatics experiments have shown to be effective due to the organization and management of this activities flow. Especially in molecular docking experiments that need HPC environments due to the manipulation of a large number of data. In this project, the main objective is to propose and evaluate a computing infrastructure that supports the life cycle of the molecular docking experiment, which aims at raising hypotheses about candidate drug targets. We propose to design the in silico molecular docking analysis as scientific workflows, managed by SWfMS and executed and evaluated in cloud computer environments. 5

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO... 9 CAPÍTULO 2 - FUNDAMENTAÇÃO TEÓRICA... 12 2.1. EXPERIMENTO CIENTÍFICO... 12 2.2. CICLO DE VIDA DE UM EXPERIMENTO CIENTÍFICO... 13 2.3. WORKFLOW CIENTÍFICO... 15 2.4. NUVENS COMPUTACIONAIS... 18 2.5. SCICUMULUS: UM MEDIADOR PARA EXECUÇÃO PARALELA DE WORKFLOWS CIENTÍFICOS EM NUVENS COMPUTACIONAIS... 20 2.6. BIOINFORMÁTICA... 21 2.7. DOENÇAS TROPICAIS NEGLIGENCIADAS... 23 2.8. MODELAGEM E ANCORAGEM MOLECULAR... 25 CAPÍTULO 3 - SCIDOCK: WORKFLOW CIENTÍFICO DE ANCORAGEM MOLECULAR 28 3.1. ESPECIFICAÇÃO DO WORKFLOW... 28 3.2. CENÁRIOS PARA AS ANÁLISES DE ANCORAGEM MOLECULAR... 28 3.3. SCISAMMA: WORKFLOW DE MODELAGEM MOLECULAR... 30 3.4. SCIDOCK: WORKFLOW DE ANCORAGEM MOLECULAR... 32 CAPÍTULO 4 - AVALIAÇÃO EXPERIMENTAL... 38 4.1. CONFIGURAÇÃO DO AMBIENTE... 38 4.2. CONFIGURAÇÃO DO EXPERIMENTO... 40 4.3. ANÁLISE DE DESEMPENHO DA EXECUÇÃO... 41 4.4. ANÁLISE DE CONSULTAS DE PROVENIÊNCIA NO SCICUMULUS... 47 4.5. APOIO À ANÁLISE BIOLÓGICA... 52 CAPÍTULO 5 - TRABALHOS RELACIONADOS... 55 CAPÍTULO 6 - CONCLUSÃO E TRABALHOS FUTUROS... 58 6.1. CONTRIBUIÇÕES... 60 6.2. LIMITAÇÕES... 61 6.3. TRABALHOS FUTUROS... 62 CAPÍTULO 7 - REFERÊNCIAS BIBLIOGRÁFICAS... 63 6

LISTA DE FIGURAS Figura 1 - Ciclo de vida do experimento científico. Adaptado de Mattoso et al. (Mattoso et al. 2010b)... 14 Figura 2 - Interseção da tecnologia com a biologia. Adaptado de Gibas (Gibas 2001).... 22 Figura 3 - Modelo chave-fechadura da ancoragem molecular.... 26 Figura 4 - Cenários caracterizados nos experimentos científicos de ancoragem molecular.... 28 Figura 5 - Modelo conceitual do workflow SciSamma.... 30 Figura 6 - Modelo conceitual dos workflow SciDock e SciDockV.... 32 Figura 7 - Um trecho da especificação do XML do SciDock para a atividade Babel.... 36 Figura 8 - Especificação no SciCumulus para a atividade Babel... 36 Figura 9 - Arquivo de parâmetro de entrada.... 42 Figura 10 - Tempo de execução (A) e speedup (B) dos workflows SciDock e SciDockV para o cenário piloto de validação.... 43 Figura 11 - Tempo de execução dos workflows SciDock (Cenário 1) e SciDockV (Cenário 3).... 44 Figura 12 - Speedup dos workflows SciDock (Cenário 1) e SciDockV (Cenário 3).... 45 Figura 13 - Tempo de execução dos workflows SciDock (Cenário 2) e SciDockV (Cenário 4).... 46 Figura 14 - Speedup dos workflows SciDock (Cenário 2) e SciDockV (Cenário 4).... 47 Figura 15 - Resultado da execução da consulta 1.... 49 Figura 16 - Resultado da execução da consulta 2.... 49 Figura 17 - Resultado da execução da consulta 3.... 50 Figura 18 - Resultado da execução da consulta 4.... 51 Figura 21 - Estruturas 3D do receptor Pfa.4PDB obtido pelo SciSamma e (B) do melhor ligante obtido pelo SciDock.... 54 7

LISTA DE SIGLAS PAD Processamento de Alto Desempenho SGWfC Sistema de Gerenciamento de Workflows Científicos NGS Da sigla em inglês Next-Generation Sequencing, DAG Grafo Acíclico dirigido, da sigla em inglês Directed Acyclic Graph XML Da sigla em inglês extensible Markup Language IAAS Infraestrutura como Serviço PAAS Plataforma como Serviço SAAS Software como Serviço MV Máquina Virtual IP Da sigla em inglês Internet Protocol ADN Ácido Desoxirribonucleico ARN Ácido Ribonucleico NCBI Da sigla em inglês National Center for Biotechnology Information UniProt Da sigla em inglês Universal Protein Resource PDB Da sigla em inglês Protein Databank PERL Da sigla em inglês Practical Extraction and Report Language OMS Organização Mundial da Saúde TDR Da sigla em inglês Special Program for Research and Training in Tropical Diseases GPF Da sigla em inglês Grid Parameter File DPF Da sigla em inglês Docking Parameter File SSH Da sigla em inglês Secure SHell UFRJ Universidade Federal do Rio de Janeiro 8

Capítulo 1 - Introdução A ancoragem molecular (Kitchen et al. 2004, Morris e Lim-Wilby 2008, Taylor et al. 2002) é considerada um experimento científico complexo e de larga escala que demanda um alto poder computacional (Kitchen et al. 2004, Mohan et al. 2005). Este experimento está formado pelo encadeamento de várias atividades (i.e., programas de bioinformática); que usualmente são executados de maneira manual pelo cientista por meio de linhas de comandos (e.g., nos programas GLIDE (Friesner et al. 2004), FlexX (Kramer et al. 1997)) ou ferramentas gráficas (e.g., AutoDockTools (Morris et al. 2009), E-Novo (Pearce et al. 2009)). Neste contexto, pesquisas relacionadas a diversas áreas da bioinformática como a ancoragem molecular podem se tornar trabalhosas e exaustivas. Por este motivo, o presente documento apresenta uma abordagem baseada na integração de workflows científicos, SGWfC e PAD com a finalidade de apoiar estes experimentos. Este projeto foca na concepção, implementação, execução e análise de workflows científicos em apoio a experimentos de ancoragem molecular, gerenciados por SGWfC e executados em ambientes de nuvens de computador. Workflows científicos executados em ambientes de processamento de alto desempenho (PAD) foram abordados para assistir experimentos científicos in silico de análises de ancoragem molecular, no apoio à descoberta de candidatos a fármacos. Durante a última década, tem havido um aumento sem precedentes no volume de dados devido especialmente às tecnologias de sequenciamento de nova geração (da sigla em inglês next-generation sequencing, NGS) (Zhang et al. 2011). Resultados obtidos a partir destas tecnologias podem contribuir para áreas da bioinformática e ancoragem molecular na identificação e desenvolvimento de novas drogas (Anderson 2003). Além da grande quantidade de dados, os experimentos de ancoragem molecular são 9

considerados como tempo e computacionalmente custosos, pelo que é preciso uma infraestrutura computacional que torne estas experimentos mais amigáveis para os bioinformatas e cientistas interessados. Sendo assim, a abordagem proposta neste projeto permite viabilizar as execuções em larga escala de experimentos científicos e explorar cenários complexos relacionados às análises de ancoragem molecular. Visam-se, desta maneira, um melhor desempenho (e.g., diminuição do tempo de processamento) e o gerenciamento do workflow, das suas atividades e dos dados de entrada/saída (i.e., por meio de consultas ao banco de dados). O presente projeto integra áreas de pesquisas interdisciplinares como são a ciência da computação, a bioinformática e as ciências da saúde. Adota-se como estratégia de pesquisa o estudo de casos, onde a avaliação da abordagem proposta é obtida a partir de valores de desempenho e de dados de proveniência através da execução do workflow científico proposto SciDock, em um ambiente de nuvem real. As seguintes etapas foram realizadas para esta pesquisa: i. Levantamento de material didático, a fim de realizar um estudo aprofundado dessas três grandes áreas (Antonopoulos e Gillam 2010, Dantas 2005, Lengauer 2002, Lesk 2008, Lindoso e Lindoso 2009, Martí-Renom et al. 2000, Mattoso et al. 2009, Morris et al. 2009, Ocaña et al. 2012b, Xu e Hagler 2002). ii. Pesquisa exploratória dos diversos experimentos da bioinformática e quimioinformática (i.e., ancoragem molecular, modelagem molecular e triagem virtual), caracterizando cenários reais envolvendo tais experiências. iii. Conceitualização e desenvolvimento do workflow científico SciDock (e SciDockV) para a ancoragem molecular e o workflow científico SciSamma para a modelagem molecular, integrados nos cenários acima caracterizados. 10

iv. Execução dos experimentos de bioinformática por meio de workflows científicos usando o motor de execução SciCumulus (Oliveira et al. 2010a) no ambiente de nuvem eleito, o Amazon EC2 1 (Amazon EC2 2010). v. Análise e inferência computacional, bioinformática e biológica a partir dos resultados obtidos, baseadas nas consultas ao banco de dados de proveniência do SciCumulus. Além deste capítulo introdutório, o texto possui outros 5 capítulos. No capítulo 2 serão apresentados os conceitos fundamentais envolvidos neste projeto, relacionados ao experimento científico, workflow científico, nuvens de computadores, SciCumulus, bioinformática, modelagem e ancoragem molecular, e triagem virtual. No capítulo 3 será detalhada a especificação dos workflows científicos de modelagem e ancoragem molecular propostos, SciSamma e SciDock, respectivamente. Já no capítulo 4 descrevese a avaliação experimental envolvendo a configuração do ambiente e do experimento, assim como as análises de desempenho e de consulta ao banco de proveniência do SciCumulus. Por fim, levantam-se as últimas considerações sobre a análise experimental envolvendo o SciDock. Os trabalhos relacionados são descritos no capítulo 5, e no capítulo 6 são apresentadas as conclusões, focando nas contribuições, limitações e trabalhos futuros do projeto. As referências bibliográficas são apresentadas no capítulo 7. 1 http://aws.amazon.com/ec2/ 11

Capítulo 2 - Fundamentação Teórica Este capítulo serve como introdução aos principais conceitos envolvidos no presente projeto. 2.1. Experimento Científico Um experimento científico pode ser definido como um teste realizado em um ambiente controlado para demonstrar a veracidade de um fato, examinar a validade de uma hipótese ou determinar a eficácia de algo ainda não testado (Soanes e Stevenson 2003) sendo uma situação criada em laboratório que visa a observar, sob condições controladas, o fenômeno de interesse (Jarrard 2001). Um experimento científico pode ser compreendido como a modelagem de etapas a serem executadas para produzir um determinado resultado (Mattoso et al. 2009). Em resumo, pode ser dito que um experimento científico é a associação sequencial de atividades controladas, para obter resultados a partir da simulação do fenômeno, com o fim de corroborar a aceitação ou rejeição de uma hipótese. Neste projeto o nosso interesse foca nos experimentos científicos in silico (Travassos e Barros 2003), termo que será utilizado repetidas vezes para referenciar aqueles experimentos que são simulados em ambientes computacionais. No geral, experimentos científicos têm a característica intrínseca de poderem ser reexecutados inúmeras vezes, dentro de condições controladas. Neste contexto, algumas informações (e.g., dados de entrada/saída, parâmetros de configuração do ambiente/ execução, erros) relacionadas ao experimento deveriam ser armazenadas com o intuito de serem usadas a posteriori nas análises e inferências dos resultados. O gerenciamento de experimentos em larga escala é especialmente complexo, devido à manipulação e produção de grandes quantidades de dados (big data) (Bertino 12

et al. 2011, Lynch 2008) e à exploração de diferentes programas envolvidos na simulação, o que leva a um alto custo computacional e de tempo (Oliveira 2012). Além disso, ter controle do volume de dados manipulados e/ou evitar ou contornar falhas de execução, o torna ainda mais complexo. Por este motivo é preciso capturar e armazenar informações que garantam a reprodutibilidade do experimento (Davidson e Freire 2008). A captura e armazenamento destes dados é uma característica fundamental para que um experimento seja considerado como científico de fato e precisa ser levado em conta pelos cientistas. Experimentos científicos são utilizados nos mais diversos domínios científicos e são pontos de inflexão que merecem o desenvolvimento de pesquisas específicas. Algumas destas áreas são: bioinformática (Ocaña et al. 2013, Oliveira et al. 2011, 2013), estudos na área de saúde (de Almeida-Neto et al. 2011, Patavino et al. 2012), ecologia (Hartman et al. 2010), agricultura (Fileto et al. 2003), estudos fisiológicos (Porto et al. 2011), prospecção de petróleo em águas profundas (Martinho et al. 2009), astronomia (Ball e Brunner 2009), dinâmica de fluidos computacional (Guerra et al. 2012), previsão de precipitação (Evsukoff et al. 2011), monitoramento aquático (Pereira e Ebecken 2011), e pesquisa sobre energia escura (Governato et al. 2010). 2.2. Ciclo de Vida de um Experimento Científico O ciclo de vida de um experimento é o termo geralmente utilizado para descrever os passos no desenvolvimento de um determinado estudo (Mattoso et al. 2010b). Ele foi proposto com o intuito de organizar e controlar toda a informação gerada ao longo do ciclo de vida de um experimento. Nele são descritas as tarefas que um cientista deve realizar ao longo da execução de um determinado experimento. Este modelo possui três fases principais: composição, execução e análise, como apresentadas na Figura 1, e que serão melhor detalhadas nos parágrafos subsequentes. 13

Figura 1 - Ciclo de vida do experimento científico. Adaptado de Mattoso et al. (Mattoso et al. 2010b). A fase de composição do experimento possui um alto nível de abstração e é nesta fase que é realizada a definição, edição e manipulação dos workflows abstratos. Aqui é definida a sequência das atividades de todo o experimento, os tipos de dados de entrada e saída e os tipos de parâmetros a serem utilizados. Esta fase, por sua vez, possui duas subfases: concepção e reuso. A concepção se encarrega da estruturação dos experimentos, a serem especificados e modelados como workflows. O reuso serve como apoio à primeira subfase, assistindo na utilização de workflows previamente criados, os quais podem ajudar na criação de outros experimentos, tanto adaptando-os quando simplesmente preparando-os para serem novamente executados (Cardoso et al. 2002, Ogasawara et al. 2009, Oliveira et al. 2010c, 2008). Na fase de execução, o modelo abstrato obtido na fase de composição é materializado, tornando-o executável para determinadas infraestruturas computacionais, tais como clusters, grades e nuvens de computadores (Dantas 2005). Nesta fase são definidos os valores dos parâmetros e os dados de entrada para cada execução. Esta fase 14

é a responsável por executar e salvar todas as informações da execução que serão usadas na última fase de análise. A fase de execução possui duas subfases: distribuição e monitoramento. A distribuição organiza as atividades a serem executadas, escolhendo quais atividades serão executadas em paralelo e distribuindo as cargas de cada máquina no ambiente distribuído. O monitoramento está encarregado de gerenciar as execuções, conferindo e recompilando informações do estado da execução, considerando que algumas execuções podem ser demoradas, levando até meses em concluir. Na terceira fase de análise é realizado o estudo dos dados obtidos nas fases anteriores. Esta fase possui duas subfases: consulta e visualização. Na subfase de consulta o cientista realiza consultas tanto nos resultados como nos dados de proveniência. Na visualização, o cientista pode optar por realizar a análise através de gráficos ou mapas que resumam as informações das consultas. Nesta fase, os cientistas devem analisar os resultados do experimento: (i) confirmando ou refutando as hipóteses levantadas na criação do experimento; (ii) recomeçando um novo ciclo podendo realizar mudanças nos parâmetros para verificar o funcionamento dele em diferentes cenários ou (iii) recriando todo o experimento com a geração de até novos workflows. O mecanismo utilizado para realizar a análise é chamado de proveniência de dados. 2.3. Workflow Científico Workflows científicos são abstrações que modelam e permitem o gerenciamento dos experimentos científicos de maneira estruturada (Mattoso et al. 2010b). Ao longo dos últimos anos os workflows científicos se tornaram um padrão para a modelagem de experimentos científicos que são baseados em simulação computacional (Mattoso et al. 2010b). Um workflow científico também pode ser definido como a especificação formal de um processo científico que representa os passos a serem executados em um determinado experimento científico (Deelman et al. 2009). 15

O workflow é constituído por atividades que representam os artefatos, programas e scripts a serem executados, onde cada atividade do fluxo de execução do workflow gera resultados que servem como dados de entrada nas atividades subsequentes. Sendo assim, ele pode ser visto como um grafo acíclico dirigido (DAG, da sigla em inglês Directed Acyclic Graph) W(A, Dep), onde os nós (A={a1, a2,..., an}) correspondem a todas as atividades (invocação de programas ou scripts) do workflow a ser executado e as arestas (Dep) estão associadas à dependência de dados entre as atividades. Dependendo da complexidade do experimento, a execução destas atividades pode requerer um alto custo computacional podendo levar de minutos a semanas ou até meses, além de serem executadas até milhares de vezes. Neste contexto, os workflows científicos podem se beneficiar de técnicas de paralelismo e ambientes de processamento de alto desempenho (Dantas 2005) (PAD). 2.3.1. Sistemas de Gerência de Workflows Científicos Workflows científicos são especificados, executados e monitorados por Sistemas de Gerenciamento de Workflows Científicos (Deelman e Chervenak 2008) (SGWfC). A utilização destes sistemas de gerenciamento permite que os cientistas se concentrem na composição e na análise do experimento científico ao invés de dedicarem seu tempo à gerência da execução (Deelman et al. 2009). Estes sistemas de gerenciamento podem ser utilizados ao longo das três fases do ciclo de vida do experimento científico: armazenamento dos dados de proveniência, monitoramento e gerenciamento da execução e finalmente a fase de consulta. Desta maneira, a ordem das atividades e serviços executados pelo workflow, assim como a definição dos parâmetros, arquivos de entrada e saída do experimento, podem ser configurados por meio dos SGWfC. Dentre os SGWfC mais usados atualmente podemos citar: VisTrails (Callahan et al. 2006), Kepler (Altintas et al. 16

2004), Taverna (Hull et al. 2006), Pegasus (Deelman et al. 2007) e Swift (Zhao et al. 2007). Cada um deles tem um algoritmo, definição e caraterísticas próprias. 2.3.2. Proveniência de Dados no Contexto de Workflows Científicos No contexto de workflows científicos, dados de proveniência são os distintos metadados associados a cada workflow que determinam a história por trás do experimento realizado, armazenando toda a informação ao longo do ciclo de vida do mesmo. Proveniência de dados, também conhecida como linhagem ou pedigree, representa a história passada de um objeto (Freire et al. 2008, Mattoso et al. 2010b). Uma definição prática da proveniência, feita pelo Dicionário Oxford de Inglês, é o registro de propriedade de uma obra de arte, indicando o autor da mesma e todos os compradores ao longo do tempo. Tal registro é utilizado como uma guia de autenticidade ou qualidade da obra. Nas pesquisas com workflows científicos, os SGWfC agrupam os detalhes de cada experimento, tais como informações sobre pesquisadores que interromperam determinado workflow e estatísticas e erros na execução dos experimentos. Estes dados de proveniência apoiam os cientistas na análise a posteriori do experimento, ou até na reprodução do mesmo, variando o ambiente (infraestrutura computacional) ou os parâmetros de entrada. Existem dois tipos de proveniência no contexto de workflows científicos: prospectiva e retrospectiva. A proveniência prospectiva (Davidson e Freire 2008) é coletada na fase de composição do experimento, salvando todas as informações da estrutura do workflow, como ordem das atividades, parâmetros de entrada e configurações do ambiente onde será executado o experimento. Já a proveniência retrospectiva (Freire et al. 2008) armazena as informações ao longo da fase de execução. Isto é, à medida que uma atividade é executada, informações 17

como tempo de início e fim, erros e resultados parciais são disponibilizadas para realizar consultas, dando uma maior flexibilidade ao cientista. Desta maneira torna-se viável interromper uma execução caso o experimento não gere resultados de acordo com o esperado ou apresente erros de execução. Assim esta intervenção pode gerar benefícios relacionados à diminuição de tempo e custo nas pesquisas. 2.4. Nuvens Computacionais Nuvens computacionais é o termo utilizado para o novo paradigma de ambientes de processamento, que surgiu com o objetivo de fornecer acesso via Web a uma série de recursos de software e hardware (Kim et al. 2009, Marinos e Briscoe 2009, Napper e Bientinesi 2009, Oliveira et al. 2010b, Vaquero et al. 2009, Wang et al. 2008). Desta forma, a ciência da computação mudou completamente devido ao acesso a todas as características inatas fornecidas pela nuvem (Oliveira 2012). Outra definição dada a este paradigma é um tipo de sistema paralelo e distribuído que consiste em uma coleção de computadores interconectados e virtualizados que são dinamicamente preparados e apresentados como um ou mais recursos de computação unificada com base em acordos estabelecidos através de negociação entre o prestador de serviços e os consumidores (Buyya et al. 2008, Vaquero et al. 2009). A nuvem tem a caraterística de possuir recursos mensuráveis e escaláveis, com uma grande capacidade de armazenamento, alta disponibilidade e usabilidade (Vaquero et al. 2009), provendo aos usuários a capacidade de realizar execuções em paralelo. Diversos modelos de negócios (i.e., dependendo da necessidade do cliente) são oferecidos pelas grandes empresas que trabalham no fornecimento de infraestrutura e processamento em nuvem (Vaquero et al. 2009). Dentre eles podemos citar três grandes categorias: Software como Serviço (da sigla em inglês Software as a Service ou SaaS), 18

Plataforma como Serviço (da sigla em inglês Platform as a Service ou PaaS) e Infraestrutura como Serviço (da sigla em inglês Infrastructure as a Service ou IaaS) (Vaquero et al. 2009). No modelo SaaS, os provedores oferecem aos usuários o acesso à aplicação, e em alguns casos, aos bancos de dados. Neste tipo de serviço, os provedores são os encarregados do gerenciamento da infraestrutura e das plataformas onde rodam as aplicações oferecidas. Um exemplo deste serviço são as alternativas on-line de aplicativos de escritório típicos, tais como processadores de texto. No modelo PaaS, em vez de oferecer uma infraestrutura virtualizada, são oferecidas as plataformas de software onde os sistemas são executados, as que costumam incluir tanto o sistema operacional como os programas. Um exemplo bem conhecido é a Engine do Google Apps 2. Finalmente, o modelo IaaS é considerado o mais básico. Através da virtualização, os provedores disponibilizam a infraestrutura, onde o usuário final é responsável por configurar o ambiente que será utilizado. Ao configurar uma única máquina virtual (MV) e logo instanciá-la inúmeras vezes, é possível reduzir consideravelmente o custo inicial das pesquisas, poupando tempo e dinheiro na instalação, configuração e manutenção de supercomputadores. Amazon EC2 é um dos grandes provedores deste tipo de serviço. 2 www.google.com/apps 19

2.5. SciCumulus: Um Mediador para Execução Paralela de Workflows Científicos em Nuvens Computacionais O SciCumulus (Oliveira et al. 2010a) é um mediador projetado para proporcionar o gerenciamento da execução de workflows científicos, quando executados em paralelo no ambiente de computação em nuvem, como Amazon EC2 (Amazon EC2 2010). O SciCumulus é o responsável pelo gerenciamento e execução das atividades do workflow científico (ou do workflow como um todo), orquestrando a sua execução em um conjunto distribuído de MV (Oliveira 2012). Ele gera uma série de tarefas para cada atividade, as quais são executadas em paralelo (e.g., uma tarefa por MV), diminuindo desta maneira a complexidade do gerenciamento das execuções em paralelo. O SciCumulus possui um mecanismo de coleta de dados de proveniência em tempo real, oferecendo o histórico de execução do workflow, que pode ser utilizado para realizar consultas ao longo da execução. O SciCumulus apresenta quatro componentes ou camadas principais: cliente, distribuição, execução, e dados (Oliveira et al. 2010a, 2010b, 2011, 2012). A camada cliente se encarrega de despachar as atividades a serem executadas na nuvem. Seus componentes são instalados nas máquinas dos cientistas. A camada de distribuição gera as atividades a serem executadas e as gerencia em uma ou mais MV instanciadas. Seus componentes podem ser instalados em qualquer ambiente, mas preferencialmente na nuvem para diminuir o impacto de comunicação com os componentes da camada de execução (Oliveira 2012). A camada de execução é a responsável pela execução das tarefas geradas na camada cliente e de todos os programas necessários no experimento. Ela é responsável por recolher os dados de proveniência ao longo da execução. Seus componentes estão instalados em todas as MV instanciadas necessárias para executar o experimento. 20

A camada de dados é a responsável por alocar os dados de entrada e saída (consumidos e gerados) durante a execução. Ela possui toda a informação sobre o ambiente distribuído onde está sendo executado tal experimento. 2.6. Bioinformática Bioinformática e Biologia Computacional são os termos utilizados para descrever a área interdisciplinar que une a tecnologia da informação com a biologia molecular (Lengauer 2002). De acordo com a definição do National Institutes of Health 3 (NIH), a bioinformática é pesquisa, desenvolvimento ou aplicação de ferramentas e abordagens computacionais para a expansão do uso de dados biológicos, médicos, comportamentais ou de saúde, incluindo aqueles usados para adquirir, armazenar, organizar, analisar ou visualizar esses dados. A disciplina relacionada de biologia computacional é o desenvolvimento e aplicação de métodos dado-analíticos e teóricos, modelagem matemática e técnicas de simulação computacional para o estudo de sistemas biológicos, comportamentais e sociais. A bioinformática provê as bases para as inferências biológicas, evolutivas, funcionais e estruturais de um sistema biológico. No entanto, ela está evoluindo devido aos avanços tecnológicos na área da biológica molecular, sobretudo com o advento de métodos de sequenciamento de nova geração (NGS), que causaram um aumento exponencial no volume da informação resultante das pesquisas biológicas. Tudo isto em conjunto torna o armazenamento, a análise e a respectiva manipulação dos dados obtidos, um dos grandes desafios da bioinformática (Lampa et al. 2013). Desta maneira, a taxa de submissão das sequências incrementou e os bancos de dados como o NCBI (Pruitt et al. 2009) (National Center for Biotechnology Information), o UniProt (The 3 www.nih.gov O NIH é a maior fonte de financiamento para a investigação médica em todo o mundo, com milhares de cientistas em universidades e instituições de pesquisa em todos os estados em toda a América e ao redor do mundo. 21

UniProt Consortium 2010) (Universal Protein Resource), e o PDB (Rose et al. 2013) (Protein Databank) atualmente contém milhões de sequências. As pesquisas realizadas pelos bioinformatas (ou biólogos computacionais) vão além da simples captura, gerenciamento e apresentação de dados biológicos. Eles se inspiram em uma grande variedade de ciências quantitativas, incluindo estatística, física, ciência da computação, e engenharia. A Figura 2 mostra como a ciência quantitativa se intersecta com a biologia em todos os níveis, a partir da análise de dados de sequência, estrutura de proteínas e modelagem metabólica, até a análise quantitativa de populações e a ecologia (Gibas 2001). Figura 2 - Interseção da tecnologia com a biologia. Adaptado de Gibas (Gibas 2001). A bioinformática não seria possível sem os avanços de hardware e software, com isso, ela está atraindo a cientistas de distintas áreas de pesquisa, especialmente da tecnologia da informação e ciências da computação. Estas áreas atualmente já estão apoiando a bioinformática em: (a) algoritmos matemáticos, para bioinformática e.g., alinhamentos de sequências (Hughey e Krogh 1996), filogenia (Yang 2007); (b) 22

algoritmos de computação gráfica, para pesquisas em bioinformática estrutural e.g., modelagem e visualização de moléculas (Callahan et al. 2006)) e (c) mineração de dados e.g., para a extração de informação biológica de bancos de dados biológicos (Chinchuluun et al. 2010, Medeiros et al. 2007); entre outros. Gerenciar experimentos de bioinformática não é uma tarefa trivial, devido à necessidade de poder computacional intensivo e do gerenciamento de dados (Greenwood et al. 2003, Oliveira et al. 2013, Stevens et al. 2007). O poder de processamento requerido aumenta com a complexidade do cenário biológico (problema biológico a resolver), a quantidade de dados consumidos/gerados e os algoritmos/programas executados para tratar estes dados. O surgimento de técnicas de computação distribuída, sistemas de banco de dados relacionados e a gerência de experimentos em larga escala seria uma solução para este tipo de problema ao dispor uma infraestrutura computacional mais flexível e escalável, capaz de responder esta demanda. Nesse contexto, este tipo de experimento científico considerado como de larga escala é candidato para ser apoiado por pipelines ou workflows científicos como foi apresentado nos Capítulo 2, subseções 2.2 e 2.3. Alguns destes experimentos requerem ser executados repetidas vezes, com parâmetros e dados de entradas distintos; situação conhecida na computação como varredura de parâmetros (Mattoso et al. 2010b). Portanto, com o apoio de técnicas e infraestruturas computacionais (ambientes de PAD), pesquisadores da biologia, química, física, astronomia, entre outros, foram migrando para a utilização de workflows científicos. 2.7. Doenças Tropicais Negligenciadas Doenças negligenciadas incluem infecções parasitárias, virais e bacterianas que atacam especialmente às populações de baixa renda nas regiões em desenvolvimento da África, 23

Ásia e América Latina. Doenças causadas por espécies de protozoários parasitas são uma das principais causas de doenças negligenciadas, e pelo fato delas estarem concentradas em áreas de baixo poder socioeconômico ao redor do mundo, elas recebem pouca atenção da indústria farmacêutica. A Organização Mundial de Saúde 4 (OMS) nomeou estas doenças como Doenças Tropicais Negligenciadas (Lindoso e Lindoso 2009) (DTN). DTN são responsáveis por milhões de mortes por ano. Embora a incidência dessas doenças seja em sua maioria em regiões tropicais, os impactos socioeconômicos e de saúde pública das DTN parasitárias são globais. O primeiro relatório sobre DTN pelo Programa Especial da OMS para Pesquisa e Treinamento em Doenças Tropicais 5 (TDR, da sigla em inglês Special Program for Research and Training in Tropical Diseases) apresentou 17 DTN endêmicas 6 em 149 países que afetam mais de 1 bilhão de pessoas (1/7 da população mundial). Além disso, elas estão se tornando resistentes aos tratamentos atuais, e o surgimento de cepas mais virulentas destes parasitas tem intensificado ainda mais a dificuldade de tratamento delas. Problemas no tratamento clínico podem ter uma origem multifatorial. A resistência a drogas se destaca como uma das principais preocupações (Arango et al. 2008). Por este motivo, novas pesquisas de drogas são necessárias para poder tratar ou até erradicar essas doenças. No entanto, o desenvolvimento de novas drogas não é uma tarefa trivial. Na verdade, é um processo trabalhoso e caro. Tipicamente, o tempo para desenvolver uma droga candidata é cerca de 10-15 anos. Neste cenário, para a maioria das doenças, o custo total entre pesquisa e desenvolvimento é de aproximadamente 60 bilhões de 4 www.who.int 5 http://www.who.int/tdr 6 Eles são: dengue, raiva, o tracoma, úlcera de Buruli, treponematoses endêmicas, lepra, doença de Chagas, tripanossomíase humana Africano, leishmaniose, cisticercose, dracunculiasis, equinococose, infecções de origem alimentar trematódeos, filariose linfática, oncocercose, esquistossomose e helmintíases transmitidas pelo solo. 24

dólares (Dickson e Gagnon 2004). Desta forma, a indústria farmacêutica evita investir no desenvolvimento de novos medicamentos candidatos para DTN, já que a população afetada é considerada de baixa renda quando a comparamos com populações afetadas por outras doenças. Em uma perspectiva financeira, DTN pode ter um baixo retorno de investimento. Para resolver estas questões, são necessários novos tipos de estudo para indicar medicamentos candidatos com custo financeiro reduzido e um tempo menor de disponibilização. 2.8. Modelagem e Ancoragem Molecular Alguns dos mais importantes avanços no planejamento e descoberta de novos fármacos (Lengauer 2002) tem sido a utilização das metodologias em experimentos de análises de modelagem, ancoragem molecular e triagem virtual. Elas têm se firmado como uma ferramenta indispensável não só no processo de descoberta de novos fármacos, mas também na otimização de um protótipo já existente ou obtido previamente. Segundo (Lesk 2008) modelagem molecular é a previsão da estrutura tridimensional (3D) de uma proteína a partir das estruturas conhecidas de uma ou mais proteínas relacionadas. A modelagem molecular por homologia (ou modelagem comparativa) refere-se ao processo de construção de um modelo de resolução atómica (modelo 3D) com base em uma sequência da proteína (alvo) e uma estrutura 3D experimental de proteínas homólogas já conhecidas (molde). A estrutura 3D do modelo molde deve ser determinada por métodos empíricos fiáveis, tais como cristalografia de raios X, espectroscopia de ressonância magnética nuclear (RMN) ou microscopia de crio-electrões para proporcionar uma elevada resolução e uma boa precisão na construção dos modelos 3D (Lengauer 2002). A ancoragem molecular refere-se à previsão da energia de ligação de um composto especificado dentro do sítio ativo da proteína-alvo (Taylor et al. 2002). Na 25

ancoragem molecular, uma estrutura 3D de um receptor (proteína) é comparada à estrutura 3D de um ligante (molécula pequena) para encontrar a melhor energia de ligação desse par receptor-ligante. Este processo foi baseado no modelo proposto por Fischer (Kunz 2002), conhecido como chave-fechadura (Jorgensen 1991), onde a proteína (fechadura) possui uma cavidade ou endentação na qual o ligante (chave) encaixa perfeitamente como indicado na Figura 3. Existem três tarefas básicas, que devem ser seguidas em todo procedimento de ancoragem: (i) determinar o local de ligação (sítio ativo do receptor), (ii) colocar o ligante no local e (iii) avaliar a força da interação entre o par receptor-ligante específico.. Figura 3 - Modelo chave-fechadura da ancoragem molecular. A estratégia de triagem virtual baseada na estrutura do alvo molecular está associada à busca de ligantes através de métodos computacionais que consideram a estrutura 3D de um alvo terapêutico. O objetivo central é o de predizer compostos de uma base de dados capazes de interagir com o sítio ligante do alvo molecular e ordenar estas moléculas de acordo com a sua afinidade pelo sítio receptor. Isto, com o intuito de identificar ligantes promissores com potencial atividade farmacológica (Kitchen et al. 2004). 26

A triagem virtual usa o poder computacional em conjunto com ferramentas de ancoragem molecular para testar grandes conjuntos de pares receptor-ligante, em poucos dias e com a baixos custos (Kitchen et al. 2004). Assim ela se torna um recurso poderoso que permite ao cientista sintetizar apenas uma reduzida amostra de compostos (i.e., aqueles selecionados) descartando as estruturas de ligantes que não possuem uma boa afinidade, diminuindo assim o grupo candidatos para os testes pré-clínicos. 27

Capítulo 3 - SciDock: Workflow Científico de Ancoragem Molecular 3.1. Especificação do Workflow Neste capítulo foram caracterizados cenários (in silico) que melhor refletem os reais cenários biológicos, bioquímicos e biofísicos (in vitro, in vivo) da ancoragem molecular. Em seguida, baseados em tais cenários são apresentados os modelos conceituais dos workflows de modelagem molecular e ancoragem molecular. 3.2. Cenários para as Análises de Ancoragem Molecular Quatro cenários foram caraterizados (Figura 4) envolvendo os workflows de ancoragem e modelagem molecular. A análise em conjunto destes workflows visa proporcionar cenários in silico que possam se assemelhar os reais cenários biológicos, bioquímicos e biofísicos de experimentos científicos in vitro ou in vivo. Figura 4 - Cenários caracterizados nos experimentos científicos de ancoragem molecular. 28

3.2.1. Cenário 1 No primeiro cenário, a estrutura 3D da proteína (receptor) não se encontra disponível no banco de dados de estruturas PDB. Neste caso, a estrutura (modelo) do receptor pode ser obtida com experimentos de modelagem por homologia. Neste projeto foi usado o workflow SciSamma. Este modelo obtido com o SciSamma é usado nas simulações de ancoragem (com um ligante) ou de triagem virtual (com um conjunto de ligantes) usando o workflow SciDock. 3.2.2. Cenário 2 No segundo cenário, a estrutura 3D da proteína (receptor) encontra-se disponível no banco de dados de estruturas PDB. Este receptor é usado nas simulações de ancoragem (com um ligante) ou de triagem virtual (com um conjunto de ligantes) usando o workflow SciDock. 3.2.3. Cenário 3 No terceiro cenário, a estrutura 3D da proteína (receptor) não se encontra disponível no banco de dados de estruturas PDB. Neste trabalho, a estrutura (modelo) do receptor foi obtida com o workflow SciSamma. Este modelo obtido com o SciSamma é usado nas simulações de ancoragem (com um ligante) ou de triagem virtual (com um conjunto de ligantes) usando o workflow SciDockV. 3.2.4. Cenário 4 No quarto cenário a estrutura 3D da proteína (receptor) encontra-se disponível no banco de dados de estruturas PDB. Este receptor é usado nas simulações de ancoragem (com um ligante) ou de triagem virtual (com um conjunto de ligantes) usando o workflow SciDockV. 29

3.3. SciSamma: Workflow de Modelagem Molecular Esta seção apresenta os detalhes do workflow SciSamma (Structural Approach and Molecular Modeling Analyses) usado nas análises de modelagem molecular. Experimentos de modelagem molecular são divididos em quatro etapas principais, onde cada etapa pode ser associada a atividades específicas do workflow SciSamma, como apresentado na Figura 5: (A) Seleção do Molde e Enovelamento atividades (1, 2); (B) Alinhamento de Sequência atividade (3); (C) Construção do Modelo atividades (4, 5); (D) Refinamento, Predição e Avaliação do Modelo atividades (6, 7, 8). Figura 5 - Modelo conceitual do workflow SciSamma. O SciSamma é composto pelas seguintes oito atividades: (1) detecção de homólogos, (2) seleção do molde, (3) construção do alinhamento, (4) construção do 30

modelo do alvo, (5) seleção da melhor estrutura do modelo, (6) refinamento do modelo, (7) previsão do modelo, e (8) a avaliação do modelo. Eles executam, respectivamente, os seguintes programas e pacotes de bioinformática com parâmetros padrão: o programa blastp do pacote BLAST (Altschul et al. 1997) 2.2.18, scripts Perl, o programa blastdbcmd do pacote BLAST, o programa align2d (Eswar et al. 2008) do pacote MODELLER 9.12, e o MODELLER (Eswar et al. 2008). A primeira atividade executa o programa blastp do pacote BLAST que compara a sequência de entrada em formato FASTA (query) contra o banco de dados de proteínas PDB (formato FASTA) obtendo como saída uma lista de sequências homólogas ou similares (BLAST hits). A segunda atividade executa um script Perl que extrai o nome do PDB do primeiro BLAST hit (sequência), que é usado como entrada no programa blastdbcmd do pacote BLAST. O blastdbcmd extrai a estrutura 3D (molde) em formato PDB do banco de dados de estruturas PDB (formato PDB) A terceira atividade executa um script Python do pacote MODELLER que converte a sequência do formato FASTA ao formato PIR, logo executa o programa align2d que constrói o alinhamento entre a sequência PIR e a estrutura PDB. A quarta atividade executa o programa MODELLER propriamente dito usando como dados de entrada a sequência PIR (query) e as informações das cordenadas da estrutura em formato PDB (molde). Como resultados são construídos 5 (o número é fixado pelo cientista) modelos estruturais em formato PDB e um arquivo log que contém informações da análise de modelagem molecular (e.g., valores de escores molpdf, DOPE, GA341) usados para comparar a qualidade referente a esses 5 modelos PDB obtidos. Um script Perl compara os escores desses 5 modelos PDB e faz a eleição do melhor. As três últimas atividades executam o MODELLER para realizar o refinamento, predição e avaliação do melhor modelo PDB obtido. 31

3.4. SciDock: Workflow de Ancoragem Molecular Esta seção apresenta os detalhes do workflow proposto SciDock para análises de ancoragem molecular. O presente projeto propõe duas variações: o SciDock propriamente dito e o SciDockV, os quais serão detalhados nos seguintes parágrafos. Experimentos de ancoragem molecular são divididos em quatro etapas principais, onde cada etapa pode ser associada a atividades específicas do workflow SciDock (ou SciDockV) apresentado na Figura 6. (A) Preparação dos Dados de Entrada atividades (1, 2, 3); (B) Geração de Coordenadas para os Mapas atividades (4, 5); (C) Preparação dos Parâmetros para a Ancoragem atividade (6); (D) Execução da Ancoragem Molecular atividade (7). Figura 6 - Modelo conceitual dos workflow SciDock e SciDockV. 32

O SciDock (e o SciDockV) é composto pelas seguintes sete atividades: (1) transformação do ligante, (2) preparação de ligante, (3) preparação de receptor, (4) preparação dos parâmetros do AutoGrid, (5) geração dos mapas de coordenadas do receptor, (6) preparação dos parâmetros para a ancoragem, e (7) execução da ancoragem. Estas atividades, respectivamente, executam os seguintes programas de bioinformática com parâmetros padrão: o Babel 2.3.2 (O Boyle et al. 2011), scripts Python do MGLTools 1.5.6 e o AutoGrid (Morris et al. 2009) do AutoDockSuite 4.2.5.1. Até este ponto o workflow SciDock e SciDockV têm a mesma composição. Já a partir das atividades (6) e (7) estes workflows se diferenciam. Para a atividade (6): (6i) o SciDock executa um script Python do MGLTools para a preparação dos parâmetros a partir dos dados de entrada e (6ii) o SciDockV executa um script Python implementado para este projeto. Para a atividade (7): (7i) o SciDock executa o AutoDock (Morris et al. 2009) do AutoDockSuite 4.2.5.1 e (7ii) o SciDockV executa o AutoDock Vina 1.1.2. A primeira atividade executa o Babel que converte o formato do ligante de SDF (.sdf ) para Sybyl Mol2 (.mol2 ). A segunda atividade executa um script Python ( prepare_ligand4.py ) do MGLTools que usa como entrada o ligante em formato Sybyl Mol2 e produz como saída o ligante em formato PDBQT (.pdbqt ). A terceira atividade executa um script Python ( prepare_receptor4.py ) do MGLTools que usa como entrada o receptor em formato PDB e produz como saída o receptor em formato PDBQT. Neste ponto, ambas as estruturas (ligante e receptor) possuem o formato PDBQT e podem ser reconhecidas pelas ferramentas de ancoragem AutoDock e Autodock Vina. A quarta atividade extrai os parâmetros contidos nos arquivos PDBQT do ligante e do receptor e gera o arquivo de saída GPF (.gpf, da sigla em inglês Grid Parameter File), reconhecido pelo AutoGrid. A quinta atividade recebe os as informações definidas 33

como parâmetros no arquivo GPF (e.g., tipos de átomos do ligante e receptor extraídos dos arquivos PDBQT) e executa o AutoGrid para a geração dos mapas do receptor 7. Como mencionado anteriormente, a sexta e sétima atividades são variantes. O workflow SciDock usa como ferramenta de ancoragem o AutoDock e o workflow SciDockV usa o AutoDock Vina. Para o SciDock, a sexta atividade extrai os parâmetros contidos nos arquivos PDBQT do ligante e do receptor e gera o arquivo DPF (.dpf, da sigla em inglês Docking Parameter File). A sétima atividade recebe os parâmetros definidos no arquivo DPF (e.g., algoritmos genéticos utilizados na ancoragem) e executa o AutoDock. O AutoDock prevê o processo de ligação do par receptor-ligante utilizando os mapas de coordenadas definidos em atividades anteriores. O arquivo gerado pelo AutoDock é um arquivo de log de execução (.dgl ) que contém informações sobre a execução do processo de ligação i.e., uma tabela de valores de RMSD (Ginalski 2006) (da sigla em inglês root-mean-square deviation), histogramas e a melhor conformação encontrada pelo AutoDock para esse par receptor -ligante. Para o SciDockV, a sexta atividade, executa o script em Python criado para este projeto e extrai a dimensão da caixa que contém a estrutura da proteína e suas coordenadas contidas no arquivo.maps.xyz, gerado na quinta atividade pelo AutoGrid, e cria um arquivo de configuração ( config.txt ). A sétima atividade recebe os parâmetros definidos no arquivo de configuração e executa o AutoDock Vina. O AutoDock Vina (assim como o AutoDock) prevê o processo de ligação receptor-ligante utilizando os mapas de coordenadas. Os arquivos gerados pelo AutoDock Vina são: um arquivo de log de execução (.txt ) que contém informações sobre o processo de 7 Os arquivos gerados pelo AutoGrid nesta atividade são: um arquivo do mapa tridimensional (.map ) para cada tipo de átomo contido no receptor; dois arquivos do mapa tridimensional (.map ) representando as energias eletrostáticas e de dessolvatação; um mapa do campo (.maps.fld '), a dimensão da caixa que contém a estrutura da proteína e suas coordenadas ( maps.xyz. ), e finalmente um arquivo de log de execução ( GLG. ). 34

ligação e a melhor conformação do par receptor-ligante e uma nova versão do arquivo PDBQT. 3.5. Detalhes da Implementação Para executar os workflows apresentados neste projeto utilizamos o mediador SciCumulus no ambiente Amazon EC2, ambiente de nuvem muito usado em diversas aplicações cientificas, como na bioinformática (Ocaña et al. 2011, 2012a, 2013, Oliveira et al. 2011, 2013). A versão utilizada do SciCumulus foi desenvolvida utilizando a linguagem Java Versão 6 Update 15. Para a camada de distribuição do SciCumulus (e consequente criação das MV na nuvem) é utilizado o MPJ. O MPJ adota a técnica de paralelismo aninhado misturando a distribuição entre processos por troca de mensagens em MPI e a execução em vários núcleos das MV por meio de threads. Por este motivo, torna-se necessária a definição do nó principal (rank 0) encarregado de atribuir as execuções aos outros nós executores (i.e., rank 1, 2 e assim por diante). Esse rank é definido em uma lista de IP (da sigla em inglês Internet Protocol) das MV instanciadas que serão utilizadas para o experimento e que são salvas no arquivo machines.conf que indica as MV que estão disponíveis para utilização. Cada MV deve ser instanciada utilizando imagens (i.e., AMI no caso do Amazon EC2). Uma imagem contém os arquivos de dados e metadados do sistema de arquivos; o código de inicialização, estruturas e atributos do sistema operacional; e os programas e scripts que serão utilizados ao longo da execução do workflow. A imagem utilizada como base das MV deve ser personalizada e configurada a priori. Devemos ter em consideração, que quando alguma mudança é necessária nas configurações do ambiente na imagem existente; uma nova imagem deve ser criada para poder salvar essas alterações. Este fato pode ser considerado como desvantagem, já que este é um processo 35

que geralmente leva um tempo considerável para ser realizado. Esta mudança na imagem se dá sempre que se realiza uma mudança permanente na configuração do workflow e.g., a instalação e/ou atualização de uma nova versão de um programa. Para que o SciCumulus gere as tarefas a serem executadas, o componente de distribuição se baseia em arquivos templates, onde são definidas as linhas de comando padrão utilizadas para invocar os programas associados a cada atividade. A organização das atividades e os dados a serem utilizados para este processo são feitas no arquivo SciCumulus.xml, onde é definida a especificação do workflow a ser executado usando o SciCumulus, como apresentado na Figura 7. Figura 7 - Um trecho da especificação do XML do SciDock para a atividade Babel. Os templates não possuem os valores reais dos parâmetros utilizados e sim tags. Ao ser executada cada atividade, o SciCumulus substitui as tags dos templates por valores reais dos parâmetros definidos no arquivo parameter.txt como apresentado na Figura 8. Após essa etapa, cada arquivo gerado a partir do template é copiado a um diretório específico onde a tarefa será executada. Figura 8 - Especificação no SciCumulus para a atividade Babel 36

A conexão entre as MV e o Desktop do cientista é feita através da utilização do protocolo SSH (da sigla em inglês Secure SHell), permitindo a carga e descarga de arquivos de dados diretamente para um sistema compartilhado de arquivos na nuvem, onde os componentes de distribuição e execução do SciCumulus foram instalados. 37

Capítulo 4 - Avaliação Experimental Esse capítulo tem o propósito de apresentar as configurações utilizadas, a avaliação experimental e os resultados obtidos ao executar os workflows SciSamma, SciDock e SciDockV. O objetivo principal deste capítulo é avaliar o desempenho e a escalabilidade das execuções destes workflows em nuvens computacionais por meio de SGWfC. Para tal, avaliamos todos os componentes apresentados neste projeto: (i) os cenários propostos, que envolvem as análises de modelagem, ancoragem molecular e triagem virtual; (ii) as consultas ao banco de proveniência do SciCumulus e (iii) o desenho, execução e análise dos workflows SciSamma, SciDock e SciDockV envolvidos nesses cenários. Primeiramente, foram caracterizados os quatro cenários, pois envolvem reais abordagens da bioinformática. Em segundo lugar, foram modelados os workflows acima citados, executados em um ambiente de nuvem distribuído usando o SciCumulus. Finalmente foram feitas as análises de escalabilidade e desempenho. Desta forma, este capítulo foi dividido da seguinte maneira: a Seção 4.1 apresenta a configuração do ambiente utilizado para a execução dos experimentos. A Seção 4.2 traz as configurações para a execução destes experimentos; enquanto que a Seção 4.3 apresenta a análise de desempenho e escalabilidade. A Seção 4.4 apresenta a análise de consultas no banco de proveniência do SciCumulus. Finalmente, na seção 4.5 descrevemos a análise biológica a partir dos dados gerados pelo experimento. 4.1. Configuração do Ambiente Para os experimentos executados neste projeto, implementamos todos os workflows usando o SciCumulus no ambiente de nuvem Amazon EC2. O Amazon EC2 fornece vários tipos diferentes de MV para os cientistas, para instanciação e uso, cada um com 38

características específicas (i.e., capacidades de CPU, de memória RAM e de armazenamento). Existem vários tipos de MV tais como a do tipo micro, small, large, e extralarge. Nos experimentos apresentados neste projeto, consideramos clusters de tamanho de até 16 instâncias do tipo large apenas. A Tabela 1 resume os dados de desempenho e precificação dos tipos de MV passíveis de uso. Tabela 1 - Configuração e preços das máquinas virtuais disponíveis. Tipo de Máquina Memória Disco UC 8 Núcleos Arquitetura Preço 9 Micro 613 MB EBS 1 1 64 Bits 0.02 Small 1.7 MB 160 GB 1 1 64 Bits 0.06 Large 7.5 MB 850 GB 2 4 64 Bits 0.34 Extra-Large 7.5 MB 1690 GB 4 8 64 Bits 0.68 As instâncias oferecidas do tipo large utilizam processadores equivalentes ao Intel Xeon quad-core. Cada MV instanciada para este projeto é baseada no sistema operacional Linux Cent OS 5 (64 bits), e foi configurada com todos os softwares necessários, bibliotecas como o MPJ (Carpenter et al. 2000) e as aplicações da bioinformática. Os programas e pacotes de bioinformática com suas respectivas versões são: BLAST 2.2.18, align2d 9.2.12, MODELLER 9.2.12, Babel 2.3.2, MGLTools 1.5.6, AutoDockSuite 4.2.5.1, e AutoDockVina 1.1.2. Todas as MV foram configuradas para serem acessadas utilizando SSH sem verificação de senha. Além disso, a imagem das MV (EC2 AMI IDs: ami-596f4d30) foram armazenadas na nuvem. O SciCumulus cria o cluster virtual para executar o experimento com base nesta imagem. Em termos de software, todas as instâncias, não importando seu tipo, executam os mesmos programas e configurações. De acordo com o 8 Uma unidade de computação (EC2 Compute Unit) é equivalente a um processador com relógio entre 1,00 e 2,33 GHz. 9 Os preços são calculados por instância-hora consumida para cada instância utilizada, a partir do momento que uma instância é lançada até que esta seja desativada ou parada. 39

Amazon EC2, todas as MV foram instanciadas na região leste dos EUA - N. Virginia e seguem as regras de preços daquela localidade. 4.2. Configuração do Experimento Os workflows de ancoragem molecular, SciDock e SciDockV e o workflow de modelagem molecular, SciSamma foram executados em determinados tipos de cenário caracterizados neste projeto, como apresentado na Figura 4. Para os cenários 1 e 3, a execução do SciSamma foi necessária em primeiro lugar. Isto devido a que muitas vezes as estruturas 3D do receptor (formato PDB), requeridas em experimentos de ancoragem molecular, não se encontram disponíveis e precisam ser modelados in silico por experimentos de modelagem molecular. Para este experimento o SciSamma utilizou como entrada 13 arquivos (formato FASTA), cada um contendo uma única sequência de aminoácidos, e gerando como saída 13 modelos em formato PDB. O SciDock (e o SciDockV) usam estes 13 modelos PDB (estrutura 3D do receptor) e os comparam com 11 arquivos SDF (ligantes específicos para esses receptores). Desta maneira, 143 combinações (pares receptorligante) são consumidas como entrada pelo SciDock (cenário 1) e pelo SciDockV (cenário 3), consequentemente 143 resultados destas análises são obtidos para cada um destes cenários. Os cenários 2 e 4 utilizam 500 entradas do par receptor-ligante a serem consumidas pelo SciDock (cenário 2) e pelo SciDockV (cenário 4), consequentemente 500 resultados destas análises são obtidos para cada um destes cenários. Este número de entradas é considerado de tamanho grande para experimentos de ancoragem molecular. Os arquivos da estrutura 3D do receptor (PDB) e do ligante (SDF) foram extraídos do banco de dados biológicos RSCB (Rose et al. 2013), obtidos por experimentos in vivo ou in vitro. 40

Desta forma, ao simular cenários reais no contexto de workflows científicos, pretendemos dar uma solução, aos problemas encontrados no desenvolvimento de experimentos de ancoragem molecular quando: i. Os dados de entrada do receptor 3D (PDB) não estão disponíveis e precisam ser modelados; ii. iii. É necessário integrar um ou mais workflows científicos. Torna-se necessário explorar o comportamento destes cenários in silico para levantar hipóteses sobre o seu comportamento computacional, e poder apoiar experimentos in vivo e in vitro; iv. Torna-se necessário explorar a variabilidade dos workflows, das suas atividades, e do tipo de recursos (ambiente, tipo e número de MV) e componentes (programas de bioinformática) requeridos em experimentos in silico. 4.3. Análise de Desempenho da Execução Os cenários de 1 a 4 propostos neste projeto foram definidos com o fim de avaliarmos o SciDock em diferentes contextos biológicos, bioquímicos e estruturais. Desde o ponto de vista computacional, cada um destes cenários foi avaliado calculando o tempo de execução e o valor da aceleração 10 (speedup) de todos os workflows. 4.3.1. Cenário Piloto de Validação Para este cenário piloto de validação, os workflows SciDock e SciDockV foram executados (e seus resultados posteriormente analisados) em um ambiente controlado. Neste contexto, foram utilizados como entradas 4 estruturas de receptores 3D cada um 10 A aceleração pode ser definida como a relação entre o tempo gasto para executar uma tarefa (no nosso caso uma cloud activity, uma atividade ou o workflow completo) com um único processador e o tempo gasto com n processadores, ou seja, a aceleração é a medida do ganho em tempo alcançado. 41

com 4 dos seus respectivos ligantes (Figura 9), todos eles disponíveis no banco de dados RCBS-PDB. Assim, este cenário usou um total de 16 pares de receptores-ligantes. Esta execução foi realizada prévia à execução dos cenários reais (1-4) com o intuito de explorar e analisar o comportamento deste tipo de workflows na nuvem usando o SciCumulus. Figura 9 - Arquivo de parâmetro de entrada. A Figura 10 mostra o tempo total de execução e o speedup dos workflows SciDock e SciDockV. Podemos observar que ao incrementar o número de processadores virtuais, o tempo de execução diminui e o speedup aumenta. Como pode ser observado na Figura 10 o workflow SciDockV apresentou um melhor desempenho quando comparado com o workflow SciDock. Por exemplo com 8 núcleos o SciDockV foi o melhor com 86.4% em termos de tempo de execução e apresentou um de speedup de 8,9. 42

Figura 10 - Tempo de execução (A) e speedup (B) dos workflows SciDock e SciDockV para o cenário piloto de validação. 4.3.2. Comparação do Cenário 1 e Cenário 3 Em primeiro lugar, o workflow de modelagem molecular SciSamma foi executado, para poder modelar estruturas 3D a serem usadas como entrada pelo workflow de ancoragem molecular SciDock (Cenário 1) e o SciDockV (Cenário 3). Para executar o SciSamma foi usado um total de 143 entradas de estruturas 3D de receptor-ligante, organizadas em 43

tuplas. Estas estruturas 3D pertencem a enzimas da família de proteases identificadas nos genomas de protozoários. O tempo de execução para esta comparação é apresentado na Figura 11 e os resultados do speedup na Figura 12. Na Figura 11 podemos observar que o tempo total de execução dos workflows SciDock e SciDockV diminui, como esperado, quando provemos uma quantidade maior de MV para processamento. O melhor desempenho foi obtido no Cenário 1 com o SciDock. Por exemplo, quando executamos o SciDock com 1 núcleo virtual, o SciCumulus necessita em média 575 minutos, enquanto que com 16 núcleos virtuais ele executa em 68 minutos. Essa diferença de desempenho levou a um pico de melhora de 88.1%. Figura 11 - Tempo de execução dos workflows SciDock (Cenário 1) e SciDockV (Cenário 3). Na Figura 12 podemos observar que o speedup dos workflows SciDock e SciDockV aumenta, como esperado, quando provemos uma quantidade maior de MV para processamento. 44

A execução do SciDock e SciDockV focado em desempenho nos levou a uma aceleração de 8.4 para o SciDock e de 7.6 para o SciDockV utilizando 16 núcleos disponíveis. Ao analisar o gráfico de aceleração apresentado na Figura 12, podemos afirmar que o SciDock e SciDockV com o SciCumulus atingiram uma aceleração quase linear quando utilizamos entre 4 e 16 núcleos no processamento. Figura 12 - Speedup dos workflows SciDock (Cenário 1) e SciDockV (Cenário 3). 4.3.3. Comparação do Cenário 2 e Cenário 4 Para executar o SciDock (Cenário 2) e o SciDockV (Cenário 4) foi testado um total de 500 pares de entradas de estruturas 3D de receptor-ligante, organizadas em tuplas. Estas estruturas 3D pertencem a enzimas da família de proteases identificadas nos genomas de protozoários. O tempo de execução para esta comparação é apresentado na Figura 13 e os resultados do speedup na Figura 14. Na Figura 13 podemos observar que o tempo total de execução dos workflows SciDock e SciDockV diminui, como esperado, quando provemos uma quantidade maior 45

de MV para processamento. O melhor desempenho foi obtido no Cenário 4 com o SciDock. Por exemplo, quando executamos o SciDock com 1 núcleo virtual, o SciCumulus necessita de 1,422 minutos em media enquanto que com 16 núcleos virtuais ele executa em 225 minutos. Essa diferença de desempenho, levou a um pico de melhora de 84.18%. Figura 13 - Tempo de execução dos workflows SciDock (Cenário 2) e SciDockV (Cenário 4). Na Figura 14 podemos observar que o speedup dos workflows SciDock e SciDockV aumentam, como esperado, quando provemos uma quantidade maior de MV para processamento. A execução do SciDock e SciDockV focado em desempenho nos levou a uma aceleração de 6 para o SciDock e de 9 para o SciDockV utilizando 16 núcleos disponíveis. Ao analisar o gráfico de aceleração apresentado na Figura 14, podemos afirmar que o SciDock e SciDockV com o SciCumulus atingiram uma aceleração quase linear quando utilizamos entre 4 e 16 núcleos no processamento. 46

Figura 14 - Speedup dos workflows SciDock (Cenário 2) e SciDockV (Cenário 4). 4.4. Análise de Consultas de Proveniência no SciCumulus Nesta seção apresentamos os resultados das diversas execuções do SciSamma, SciDock e SciDockV com o SciCumulus materializados sob a forma de consultas baseadas no repositório de proveniência. A função destas consultas é recuperar os descritores de proveniência que foram previamente coletados pelo SciCumulus ao executar estes workflows na nuvem do Amazon. As consultas consideradas nesta seção representam um subconjunto de consultas previamente definidas pelos pesquisadores que utilizam os workflows SciSamma, SciDock e SciDockV. Todas as consultas foram executadas na base de proveniência instanciada com o PostgreSQL 8.4 na MV: ec2-50-17-107-164.compute- 1.amazonaws.com, imagem: AMI: BioSciCumulus (ami-6e1a8907). A base em questão contém aproximadamente 310,000 atividades geradas e 1,240,000 arquivos produzidos nas mais de 450 execuções do SciSamma, SciDock e SciDockV. 47

As consultas foram baseadas nos dois tipos de proveniência apresentadas na seção 2.3.2. Elas foram classificadas nos seguintes dois grupos: i. Consultas envolvendo descritores de proveniência prospectiva; ii. Consultas envolvendo descritores de proveniência retrospectiva. A seguir apresentamos uma série de consultas formuladas em SQL (o banco de dados utilizado para representar o repositório de proveniência é relacional) elaboradas a partir da necessidade da Dra. Kary Ann del Carmen Soriano Ocaña, especialista em bioinformática que acompanhou a execução dos experimentos apresentados neste projeto. 4.4.1. Consultas de Proveniência Prospectiva Consulta 1: Recuperar, por ordem crescente de identificador dos workflows as atividades relacionadas a cada workflow e as tarefas associadas a cada atividade. SELECT FROM WHERE AND ORDER BY w.tag, w.description, a.tag, t.workspace hworkflow w, hactivity a, hactivation t w.wkfid = a.wkfid a.actid = t.actid w.wkfid A consulta 1 é uma consulta básica de proveniência, a qual permite ao cientista ter uma visualização geral da estrutura dos workflows que foram ou estão sendo executados. O resultado da consulta 1 é mostrado na Figura 15. Este tipo de consulta representa uma consulta de proveniência prospectiva. 48

Figura 15 - Resultado da execução da consulta 1. Consulta 2: Recuperar todos os workflows que contém uma determinada atividade chamada autogrid4. SELECT w.wkfid, w.tag, w.exectag, w.description FROM hworkflow w WHERE EXIST (SELECT 1 FROM hworkflow w2, hactivity a WHERE w2.wkfid = w.wkfid AND w2.wkfid = a.wkfid AND a.tag = autogrid4 ) Esta consulta 2 tem como objetivo auxiliar o cientista na descoberta de workflows já existentes i.e. que foram executados e que possam ser reaproveitados. O resultado da consulta 2 é mostrado na Figura 16, e as informações obtidas do resultado desta consulta fomentam o reuso de workflows. Figura 16 - Resultado da execução da consulta 2. 49

4.4.2. Consultas sobre Proveniência Retrospectiva Consulta 3: Recuperar, por ordem crescente da hora de término das execuções do workflow com identificador 450, as datas e horas de início e término, tags dos workflows e suas descrições, bem como o nome de todas as atividades associadas junto com as durações das mesmas. SELECT t.taskid, t.actid, w.tag, t.exitstatus, t.processor, t.workspace, t.status, t.endtime, t.starttime, extract ('epoch' from (t.endtime-t.starttime)) ',' as duration FROM hworkflow w, hactivity a, hactivation t WHERE w.wkfid = a.wkfid AND a.actid = t.actid AND w.wkfid = 450 ORDER BY t.endtime A consulta 2 é fundamental para o cientista, pois permite a monitoração em tempo real das execuções de cada workflow, dando ao cientista a oportunidade de modificar o curso da execução, i.e., termina-la antes do fim, no caso de estado de erro de atividades fundamentais para o estudo. O resultado da consulta 3 é mostrado na Figura 17. É importante relembrar que tal análise somente é possível graças a proveniência do SciCumulus sendo gerada em tempo de execução. Figura 17 - Resultado da execução da consulta 3. 50

Consulta 4: Recuperar os nomes, tamanhos e localização dos arquivos com a extensão.dlg que foram produzidos em todas as execuções do workflow SciDock. Recuperar juntamente qual workflow e qual atividade produziu o arquivo. SELECT FROM WHERE AND AND AND AND w.tag, a.tag, f.fname, f.fsize, f.fdir hworkflow w, hactivity a, hactivation t, hfile f w.wkfid = a.wkfid a.actid = t.actid f.taskid = t.taskid w.tag like '%SciDock%' f.fname like '%dlg%' Similarmente à consulta 3, esta consulta 4 é fundamental para o monitoramento da execução de um workflow em tempo real, pois permite ao cientista descobrir os arquivos que estão sendo gerados. O resultado da consulta 3 é mostrado na Figura 18. No caso da ancoragem molecular esta consulta 4 apoia à análise biológica pois permite determinar primeiro se algum tipo de mensagem é gerado durante a criação do arquivo e segundo se arquivo em questão foi obtido com sucesso e qual a localização do mesmo. Desta maneira o cientista baseia-se nestes resultados e auxilia-se de uma ferramenta gráfica apropriada para verificar a estrutura 3D obtida após a ancoragem. Esta verificação pode ser feita em tempo real. Figura 18 - Resultado da execução da consulta 4. 51

4.5. Apoio à Análise Biológica Nesta seção serão abordados alguns pontos importantes relacionados às análises biológicas. Entre eles: (i) o tipo de dados biológicos usados/gerados, (ii) o uso de consultas ao banco de dados de proveniência do SciCumulus para obter informações biológicas contidas nesses dados e (iii) as inferências biológicas levantadas. Para este projeto foram utilizados os dados biológicos (i.e., sequências e estruturas 3D) de uma família de enzimas de proteases (i.e., cisteíno proteases, CP) pertencentes aos genomas completos de protozoários que causam algumas das mais conhecidas DTN, como a malária. Atualmente existem várias pesquisas em andamento para desenvolver novos medicamentos quimioterápicos contra a malária. A bioinformática tem se tornado uma ferramenta valiosa para este tipo de pesquisas de experimentos in silico. Por outro lado, o gerenciamento de experimentos de bioinformática está longe de ser trivial devido ao grande volume de dados biológicos, o que demanda um ambiente PAD. E devido à grande quantidade de arquivos existente, esta tarefa é suscetível a erros quando realizada manualmente. Diversos SGWfC (Mattoso et al. 2010b) registram a execução dos workflows destes experimentos por meio de dados de proveniência (Moreau et al. 2008). E são estes dados de proveniência que fornecem importante documentação ao cientista sobre o processo usado para preservar os dados e a qualidade e a origem desses dados; permitindo desta maneira reproduzir, interpretar e validar os resultados científicos gerados por experimentos, como os abordados no presente projeto. A proveniência de dados pode ser consultada de várias maneiras para extrair os parâmetros que levaram a resultados específicos. Ela também pode ser usada para verificar se um determinado arquivo de dados foi de fato gerado e quais são os 52

parâmetros que foram consumidos. Particularmente, em workflows de modelagem e ancoragem molecular onde milhares de arquivos de dados intermediários são produzidos. Os cientistas têm que analisar cada um desses arquivos, associar o seu conteúdo à atividade que os gerou e estabelecer quais parâmetros foram consumidos para produzi-los. A proveniência fornece automaticamente associações entre parâmetros e arquivos de dados. O SciCumulus gerencia a execução paralela do SciSamma, SciDock e SciDockV aplicando o mecanismo de varredura de parâmetros (Mattoso et al. 2010a) e cria um cluster virtual formado por várias MV. Cada VM processa atividades independentes, consumindo diferentes dados de entrada em paralelo. Todos os dados de proveniência relacionados ao SciSamma, SciDock e SciDockV são capturados e gerenciados automaticamente pelo SciCumulus. O SciCumulus já foi testado com sucesso em outros experimentos de bioinformática computacionalmente complexos e intensivos e.g., SciPhy (Ocaña et al. 2011) e SciHmm (Ocaña et al. 2013), SciPhylomics (Oliveira et al. 2013), SciEvol (Ocaña et al. 2012a). O seguinte resultado experimental reforça a importância da exploração destes dados de proveniência para ajudar os cientistas nas suas inferências relacionadas às análises de modelagem e ancoragem molecular. Nas análises de ancoragem molecular foram usados como dados de entrada as estruturas em PDB (tanto as disponíveis no banco RCSB-PDB, como as criadas pelo SciSamma). Na Figura 19 mostramos um dos resultados do experimento de ancoragem molecular usando o SciDock e SciDockV. A base de dados do SciCumulus foi consultada e: foram obtidos todos os arquivos log finais e as estruturas 3D do seus 53

respectivos ligantes e receptores, que foram gerados sem erro pelas atividades do SciDock e SciDockV. (A) Estrutura 3D do receptor Pfa.4PDB (B) Estrutura 3D do ligante específico do Pfa.4PDB Figura 19 - Estruturas 3D do receptor Pfa.4PDB obtido pelo SciSamma e (B) do melhor ligante obtido pelo SciDock. Os arquivos log obtidos com a consulta anterior contêm os valores de afinidade dos ligantes testados com o receptor alvo (Pfa.4PDB), assim como, qual ligante é o melhor de todos baseado no método de predição de posicionamento do ligante no sítio de ligação. A Figura 19 mostra a estrutura 3D do receptor (Pfa.4PDB) obtido com o SciSamma com o seu respectivo ligante de maior afinidade obtido com o SciDock (e SciDockV). Foi demonstrado pelo SciDock (e SciDockV) que pode ser possível testar esses ligantes in silico e compará-los com os receptores de interesse (i.e., enzimas proteases candidatos a drogas) e que estas informações podem ser mapeadas via consultas SQL. 54