sistema para simulaÇÃo interativa de dinÂmica...
TRANSCRIPT
“Faz forte ao cansado, e multiplica as forcas ao que nao tem nenhum vigor. Osjovens se cansam e se fatigam, e os mocos de exaustos caem, mas os que espe-ram no Senhor renovam as suas forcas, sobem com asas como aguias, correme nao se cansam, caminham e nao se fatigam.”
ISAIAS 40:29-31
AGRADECIMENTOS
Agradeco a meus pais, Antonio Souza e Maria de Fatima, pelo que sou hoje e pelo incentivo
que sempre me deram.
Ao Programa de Pos-Graduacao em Computacao Aplicada (CAP), pelo curso de alta
qualidade que professores e alunos se esforcam em fazer. Ao Laboratorio Associado de
Computacao e Matematica Aplicada (LAC) e ao Instituto Nacional de Pesquisas Espaciais
(INPE), pelo aprendizado e oportunidades que me proporcionaram.
Aos meus orientadores, Dr. Stephan e Dr. Airam, pela orientacao, dedicacao e paciencia.
A Fundacao de Amparo a Pesquisa do Estado da Bahia (FAPESB), pelo auxılio financeiro
de dois anos de bolsa de mestrado. Tambem gostaria de agradecer a Fundacao de Amparo
a Pesquisa do Estado de Sao Paulo (FAPESP), que financiou o projeto 01/03100-9, Para-
lelizacao de Aplicacoes em Fısica dos Materiais num Ambiente de Memoria Distribuıda,
no qual este trabalho esta inserido.
Ao Dr. Enzo Granato e ao Dr. Leonel F. Perondi, do Laboratorio de Sensores e Materiais
(LAS), pelo suporte e sugestoes.
A minha famılia, em especial minha irma, Patrıcia e minha prima, Dezilene.
Aos meus colegas, pela amizade e companheirismo demonstrados.
Agradeco a Sra. Neusa Buto e sua famılia pela hospitalidade com que me receberam em
Sao Jose dos Campos.
Agradeco a todas as pessoas que de forma direta e indireta tornaram esse trabalho possıvel,
nao apenas nos dois anos que trabalhei nele, mas tambem antes, como meus professores
e colegas da Universidade do Estado da Bahia (UNEB).
RESUMO
Este trabalho apresenta uma implementacao proposta para paralelizacao de simulacoesinterativas de Dinamica Molecular (DM) utilizando o ambiente PyMPI, o qual estende alinguagem Python para o execucao paralela atraves da biblioteca de comunicacao MPI.Utilizou-se como estudo de caso o ADKS, que e um software interativo para simulacoesde DM aplicadas a defeitos em solidos, tais como fraturas e contornos de grao. Uma ma-quina paralela de memoria distribuıda composta de 5 nos biprocessados foi empregada.Inicialmente, paralelizou-se o motor de simulacao do ADKS utilizando-se a abordagemde decomposicao espacial do domınio entre processadores e a biblioteca MPI. Empregou-se comunicacao nao bloqueada para otimizar o desempenho computacional, obtendo-seentao speedups proximos do linear nos casos analisados. As simulacoes interativas para-lelas foram modeladas como um automato finito e implementadas por meio do ambientePyMPI. O motor de simulacao foi entao integrado a esse ambiente de forma que suas ro-tinas associadas sejam acessıveis ao usuario na forma de comandos. Um novo modulo devisualizacao foi integrado a simulacao interativa e executado no no mestre, que executaa interface de usuario. Esse modulo e baseado naquele do ADKS e exibe as partıculasem uma janela grafica. O desempenho paralelo das simulacoes interativas foi ligeiramenteinferior ao do motor de simulacao devido a comunicacao das coordenadas atualizadasdas partıculas ao processador mestre. Testes com simulacoes especıficas demonstraram aviabilidade da abordagem proposta.
SYSTEM FOR INTERACTIVE MOLECULAR DYNAMIC SIMULATIONIN A PARALLEL ENVIRONMENT
ABSTRACT
This work presents a proposed implementation of a Molecular Dynamics (MD) interac-tive simulator. It employs the PyMPI environment, that extends the Python language forparallel execution by means of the MPI communication library. The ADKS was chosenas a case study. It is an interactive software for MD simulations aimed at defects in solidmaterials, such as fractures and grain boudaries. A distributed memory parallel machinecomposed of 5 biprocessor nodes was employed. In a first step, the ADKS simulationengine was parallelized by means of the MPI library and the partition of the simula-tion domain among processors. In order to optimize the computational performance, nonblocking communication was employed. As a result, speedups very close to linear wereobtained in the test cases. The parallel interactive simulations were modelled as a finiteautomata and implemented by means of the PyMPI environment. The simulation enginewas integrated to this environment in such a way that its routines were made available asuser commands. A new visualization module was integrated to the interactive simulationand executed in the master node, that runs the user interface. This module is based onthe original ADKS one and displays the particles in a graphical window. The parallelperformance of the simulation coupled to visualization was slightly lower than that ofthe stand alone simulation engine. This is due to the communication that is required toupdate the particle coordinates in the master node. Specific test cases were executed withvisualization showing the feasibility of the proposed approach.
SUMARIO
Pag.
LISTA DE FIGURAS
LISTA DE TABELAS
1 - INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 -SIMULACOES EM DINAMICA MOLECULAR . . . . . . . . . . . . 23
2.1 - Potencial Intermolecular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 - Integracao das Equacoes de Movimento . . . . . . . . . . . . . . . . . . . . . . 25
2.3 - Condicoes de Contorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 - Algoritmo Basico de Simulacao de Dinamica Molecular . . . . . . . . . . . . . 27
2.5 - Consideracoes sobre Complexidade Algorıtmica . . . . . . . . . . . . . . . . . 30
3 -PROCESSAMENTO PARALELO . . . . . . . . . . . . . . . . . . . . . 33
3.1 - Arquiteturas de Computadores Paralelos . . . . . . . . . . . . . . . . . . . . . 33
3.2 - Particionamento do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 - Modelos de Programacao Paralela . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 - Ferramentas de Programacao Paralela . . . . . . . . . . . . . . . . . . . . . . 40
3.4.1 - A Biblioteca de Comunicacao MPI . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 - Metricas de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 -MOTOR PARALELO PARA SIMULACAO DE DINAMICA MOLE-
CULAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 - A Demanda por Desempenho em Dinamica Molecular . . . . . . . . . . . . . . 47
4.2 - Metodos para Paralelizacao em Dinamica Molecular . . . . . . . . . . . . . . . 48
4.3 - Arquitetura Empregada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 - Ferramentas Empregadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 - Decomposicao do Domınio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 - Algoritmo Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 - Validacao do Algoritmo Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . 58
4.8 - Escalabilidade de Simulacoes de Dinamica Molecular . . . . . . . . . . . . . . 59
4.9 - Resultados de Desempenho Paralelo . . . . . . . . . . . . . . . . . . . . . . . . 62
5 -SIMULACOES INTERATIVAS EM DINAMICA MOLECULAR . . 67
5.1 - A Demanda por Interatividade em Dinamica Molecular . . . . . . . . . . . . . 67
5.2 - Estudo de Caso: o Software ADKS . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 - Solucoes Existentes para o Problema da Interatividade em Ambiente Paralelo 69
5.4 - Questoes sobre Interatividade na Arquitetura Empregada . . . . . . . . . . . . 71
5.5 - O Ambiente PyMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.6 - Desenvolvimento de Extensoes para Python e PyMPI . . . . . . . . . . . . . . 74
5.7 - Integracao Desenvolvida da Visualizacao com o Motor de Simulacao . . . . . . 76
5.8 - Resultados de Desempenho Paralelo . . . . . . . . . . . . . . . . . . . . . . . . 79
6 -CONCLUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1 - O Motor Paralelo de Dinamica Molecular Desenvolvido . . . . . . . . . . . . . 85
6.2 - Implementacao Desenvolvida para Simulacoes Interativas e Paralelas de Dina-
mica Molecular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.3 - Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
REFERENCIAS BIBLIOGRAFICAS . . . . . . . . . . . . . . . . . . . . . 89
LISTA DE FIGURAS
Pag.
2.1 Potencial de Lennard-Jones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Condicao de contorno periodica. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Metodos de calculo das forcas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Uniform Memory Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Exemplo de Multi-computador. . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Modelos de programacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Modelo de programacao por troca de mensagens. . . . . . . . . . . . . . . . . 38
3.5 Comparacao entre memoria compartilhada e rede Gigabit Ethernet. . . . . . . 39
3.6 Speedup sob a perspectiva da lei de Amdahl. . . . . . . . . . . . . . . . . . . . 45
4.1 Matriz de forcas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Decomposicao em cubos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Decomposicao em faixas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Grade de celulas local ao processador 2. . . . . . . . . . . . . . . . . . . . . . 55
4.5 Primeiro passo do calculo das forcas. . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 Exemplos do padrao de varredura das celulas. . . . . . . . . . . . . . . . . . . 57
4.7 Tempos de execucao para a maquina paralela nCube inferidos de (PLIMPTON,
1995). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.8 Speedup do codigo de DM em execucao intra-no. . . . . . . . . . . . . . . . . . 64
4.9 Comparacao entre execucao do codigo de DM intra-nos e inter-nos. . . . . . . 65
5.1 Defeitos em solidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Visao geral da solucao de Beazley e Lomdahl. . . . . . . . . . . . . . . . . . . 71
5.3 Modelo baseado em automatos finitos. . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Imagem executavel da abordagem monolıtica. . . . . . . . . . . . . . . . . . . 73
5.5 Ambiente PyMPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Integracao da interface de usuario e o motor de simulacao. . . . . . . . . . . . 77
5.7 Interface e Visualizacao no ambiente PyMPI. . . . . . . . . . . . . . . . . . . 78
5.8 Speedup do motor de simulacao acoplado a visualizacao. . . . . . . . . . . . . 80
5.9 Contorno de grao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.10 Fraturas ruptil e ductil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
LISTA DE TABELAS
Pag.
2.1 Tempos das principais funcoes de uma simulacao de DM. . . . . . . . . . . . . 30
4.1 Tempo de processamento em segundos para 1, 2, 4 e 8 processadores e n par-
tıculas (esquema intra-no). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Speedup para n partıculas em 1, 2, 4 e 8 processadores (esquema intra-no). . . 63
4.3 Tempo de processamento em segundos para 1, 2, 4 processadores inter-nos. . . 64
5.1 Funcoes do software ADKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Tempo de execucao de 100 timesteps. . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Parametros para os exemplos de contorno de grao. . . . . . . . . . . . . . . . . 81
5.4 Tempo de execucao de 5.300 timesteps para simulacao de contorno de grao
simetrico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5 Tempo de execucao de 7.000 timesteps para simulacao de contorno de grao
assimetrico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6 Parametros para os exemplos de fraturas. . . . . . . . . . . . . . . . . . . . . . 82
5.7 Parametros de tamanho dos exemplos de fraturas. . . . . . . . . . . . . . . . . 83
5.8 Tempo de execucao de 1.567 timesteps para simulacao de fratura ductil. . . . 83
5.9 Tempo de execucao de 1.500 timesteps para simulacao de fratura ruptil. . . . . 83
1 INTRODUCAO
Computadores sao sem duvida um importante instrumento da ciencia moderna, sendo uti-
lizados em diversas areas, como biologia, economia, fısica, e com diversas finalidades, como
analise numerica, processamento de transacoes e controle em tempo real de dispositivos.
Uma das finalidades de uso da computacao que tem evoluıdo e se mostrado bastante
util e a simulacao em computador. Em linhas gerais uma simulacao em computador e
um programa que inclui as leis basicas de um modelo para a realizacao de experimentos
numericos. As razoes para uso de simulacoes ao inves de experimentos reais variam desde
questoes economicas para realizacao do experimento ate a impossibilidade total de sua
realizacao, como em simulacoes de astrofısica.
Em fısica, biologia, quımica e outras ciencias um tipo de simulacao que tem sido empregada
com sucesso e a simulacao de Dinamica Molecular (DM), a qual objetiva o estudo da
materia em nıvel atomico, e em sua forma mais simples se resume ao calculo das trajetorias
de um numero finito de partıculas, tipicamente atomos ou moleculas, a partir do potencial
de interacao entre as partıculas. Dado um potencial, pode-se calcular a forca resultante em
cada partıcula e, por meio da segunda lei de Newton, atualizar sua velocidade e posicao.
Conhecido o comportamento microscopico dos atomos ou moleculas em uma simulacao
de dinamica molecular, pode-se extrair informacoes para interpretacao de fenomenos em
escala macroscopica. DM e usada em nanotecnologia para simular engrenagens baseadas
em nanotubos (HAN et al., 1997) e nanomotores (TUZUN et al., 1995), em biologia, para o
estudo de doencas (LINS et al., 1999) e simulacao de biomoleculas (KARPLUS; MCCAMMON,
2002), em ciencia dos materiais para simular propriedades de materiais (HEINO et al., 1998)
e defeitos em solidos (KASKI et al., 1998), so para citar alguns poucos exemplos.
Simulacoes em geral, e simulacoes de dinamica molecular em particular, podem tomar a
forma de um programa executado no modo batch, em que o processo de simulacao pode
ser descrito como um ciclo que se inicia com a definicao dos dados de entrada, seguida
da execucao da simulacao, do pos-processamento e uma eventual redefinicao dos dados
de entrada, iniciando-se um novo ciclo. Uma alternativa a essa abordagem e permitir
a visualizacao das partıculas e a alteracao de parametros da simulacao em tempo de
execucao, constituindo o que se denomina simulacao interativa. A capacidade de se ajustar
parametros e de se obter resultados visuais durante execucao fornece um ambiente que
facilita a compreensao do sistema simulado e a percepcao de fenomenos que dificilmente
seriam conseguidos em analise pos-morten de uma simulacao em modo batch, sendo que
alguns autores chegaram a prever o fim das simulacoes em modo batch, (EISENHAUER et
al., 1994).
19
Em (RAPAPORT, 1997) e apresentado um exemplo ilustrativo de simulacao de dinamica
molecular interativa que inclui animacao com o proposito didatico. O sistema simulado
representa um sistema simples de moleculas esfericas de um fluido interagindo sujeitas ao
potencial de Lennard-Jones, entretanto a tecnica apresentada pode ser usada em proble-
mas mais complexos. O modelo de programacao usado e baseado em eventos e para dar
suporte a essa abordagem foi usado o ambiente grafico X11, tıpico do sistema Unix, e a
biblioteca de componentes Motif. Programar com X11 e Motif e uma tarefa relativamente
complexa e um dos objetivos desse artigo e fornecer ao leitor um exemplo que pode ser es-
tendido e adaptado as necessidades especificas. Um segundo exemplo pode ser encontrado
em (MERIMAA et al., 2000), diferente de (RAPAPORT, 1997) esse artigo nao apresenta e
comenta o codigo-fonte de um programa de DM, mas mostra as caracterısticas e funcio-
nalidades de um software chamado ADKS para simulacao de fraturas e contorno de grao
(grain boundary) em solidos. O ADKS tem seu codigo-fonte disponıvel na biblioteca de
programas CPC (Computer Physics Communications Program Library) e e inspirado no
artigo (RAPAPORT, 1997). Mais detalhes do ADKS serao mostrados no Capıtulo 5 pois
esse software foi usado como estudo de caso neste trabalho.
Quando o potencial entre atomos de uma simulacao de dinamica molecular tem alcance
curto, algoritmos eficientes como o algoritmo de divisao por celulas e o algoritmo de
lista de vizinhos descritos em (RAPAPORT, 1995) e no Capıtulo 2 podem ser usados.
Entretanto, existem situacoes em que mesmo algoritmos eficientes nao conseguem tratar
em tempo satisfatorio a quantidade de partıculas que se deseja simular, principalmente
em simulacoes interativas, pois os fenomenos observados devem ocorrer em um tempo
confortavel ao usuario que os assiste. Nessas situacoes processamento paralelo pode ser
usado para viabilizar as simulacoes e a interatividade.
Um artigo relativamente conhecido (PLIMPTON, 1995), apresenta tres algoritmos para
paralelizacao de simulacoes de dinamica molecular com potencial de curto alcance. O
primeiro divide os N atomos da simulacao entre os P processadores de um computador
paralelo, sendo cada processador responsavel pelo calculo das forcas e atualizacao das
posicoes dos seus atomos, mas a computacao e O(N/P ) gracas ao uso de lista de vizinhos
que restringe os calculos apenas as interacoes entre partıculas vizinhas. A comunicacao,
entretanto, e O(N), pois as partıculas proximas a uma certa partıcula de um processador
PN podem estar em qualquer processador, dessa forma todos os processadores necessi-
tam das posicoes atualizadas de todas as partıculas para calcular as forcas. O segundo
algoritmo divide as forcas entre processadores, sendo cada processador responsavel pelo
calculo das forcas entre dois subconjuntos de atomos. A computacao ainda e O(N/P ),
mas nao e mais necessaria a comunicacao da posicao de todos os atomos, apenas aquelas
20
necessarias para o calculo das forcas locais. O ultimo algoritmo particiona o espaco entre
os processadores. A comunicacao e reduzida as bordas da regiao de cada processador,
mas a computacao pode nao ser O(N/P ) para todos os processadores se os atomos se
acumularem em regioes especıficas do espaco, causando desbalanceamento de carga.
Uma questao que surge em relacao aos fatores interatividade e paralelismo apresentados
e: como controlar em tempo de execucao a simulacao paralela em resposta a interacao
com o usuario? Em (GU et al., 1998) e apresentada uma solucao, o sistema Falcon, que e
composto de um conjunto de ferramentas, bibliotecas e interfaces de usuario para capturar
dados de codigos paralelos, analisar e exibir esses dados e permitir configuracao em tempo
de execucao do programa, quer por um usuario, quer por um programa. Entretanto,
como essa solucao se baseia fortemente em threads e exige uma maquina com memoria
compartilhada, seu uso parece restrito. Isso e agravado pela escalabilidade limitada dessa
classe de maquinas.
Em (BEAZLEY; LOMDAHL, 1997) e apresentado um ambiente de execucao interativa e
paralela baseada na linguagem de programacao Python. Tambem e apresentado como esse
ambiente possibilita controle em tempo de execucao de um codigo de dinamica molecular, o
SPaSM (Scaleable, Parallel, Short-Range Molecular Dynamics). O ambiente desenvolvido
se baseia na biblioteca de troca de mensagens MPI, o que permite sua execucao numa
gama mais ampla de arquiteturas que o Falcon. O que mais chama a atencao nessa solucao
e a capacidade de extensao do sistema, sendo que novos modulos podem ser desenvolvidos
e agregados ao nucleo inicial de forma simples. Um sistema semelhante ao de (BEAZLEY;
LOMDAHL, 1997) e encontrado em (JABLONOWSKI et al., 1993), em que codigos Fortran
sao executados num ambiente interativo.
O presente texto tem como objetivo propor um sistema paralelo e interativo para simu-
lacao de dinamica molecular que pode ser estendido e adaptado a diversos problemas de
DM. A arquitetura paralela usada aqui e a de memoria distribuıda em que a rede de
interconexao dos processadores e mais lenta que o acesso a memoria, sendo assim uma
forma de paralelizacao e proposta visando ocultar o tempo de comunicacao. O problema e
particionado segundo uma das possibilidades apresentadas em (PLIMPTON, 1995), a divi-
sao espacial do domınio. Um conjunto de processador da maquina paralela (back-end) fica
responsavel pelo calculo das trajetorias das partıculas que lhes cabe da divisao do domınio.
Esses processadores atualizam a um determinado numero de timesteps um processador
responsavel pela visualizacao e pelo terminal de interacao com o usuario (front-end). Co-
mandos fornecidos pelo usuario modificam o comportamento dos processadores back-end,
como por exemplo modificar a temperatura do sistema de partıculas. Dessa forma o soft-
ware executando em back-end pode ser visto como um automato finito cujas transicoes
21
sao disparadas por comandos no front-end. O ambiente pyMPI, que e uma extensao do
Python para maquinas paralelas, foi usado para integrar o software paralelo de calculo das
trajetorias com a interface de usuario, pois se trata de um ambiente interativo e facilmente
extensıvel atraves de bibliotecas de vınculo dinamico, o proprio software de calculo das
trajetorias foi desenvolvido como uma biblioteca. O software ADKS, que e sequencial, foi
paralelizado conforme a metodologia descrita resumidamente acima e seus resultados sao
apresentados aqui.
O Capıtulo 2 apresenta uma descricao mais detalhada das simulacoes de dinamica mole-
cular. Um algoritmo basico e mostrado e sao descritos os algoritmos mais comuns, divisao
por celulas e lista de vizinhos. No Capıtulo 3 sao descritas arquiteturas paralelas, modelos
de programacao paralela e algumas ferramentas de programacao paralela. O Capıtulo 4
trata da paralelizacao do calculo das trajetorias. Nesse capıtulo e apresentada em mais
detalhes a arquitetura usada, e discutida como conseguir ocultar o tempo de comunicacao
nessa arquitetura . E apresentado tambem o algoritmo desenvolvido e resultados para um
caso simples de DM. O quinto capıtulo mostra como foi implementada a integracao da
simulacao com a interface de usuario. Nesse capıtulo e apresentado o Python e o PyMPI e
como eles foram usados. Ainda no Capıtulo 5, e apresentado o ADKS e os resultados de sua
paralelizacao segundo a estrategia desenvolvida. O ultimo capıtulo contem as conclusoes
e trabalhos futuros.
22
2 SIMULACOES EM DINAMICA MOLECULAR
Simulacao de Dinamica Molecular (DM) e uma tecnica computacional usada no estudo da
materia em nıvel atomico. Essa tecnica consiste em se calcular as trajetorias de partıculas,
como atomos e moleculas, que individualmente obedecem as leis classicas de movimento,
para obter propriedades do sistema (HEERMANN, 1990). Correcoes semi-classicas podem
ser incorporadas para tratar os efeitos quanticos (ALEN, 1993).
Esse tipo de simulacao e semelhante as simulacoes da astrofısica para corpos celestes,
que e um problema N-Body e sendo assim nao tem solucao analıtica. Os metodos para
resolucao de problemas N-Body podem ser, portanto, empregados em dinamica molecular.
Diversas areas do conhecimento usam Simulacoes de Dinamica Molecular com sucesso.
Em nano-tecnologia elas sao usadas para simular nano-dispositivos como engrenagens e
bombas, (HAN et al., 1997) e (CAGIN et al., 1998). Em bioquımica sao simuladas biomolecu-
las (KARPLUS; MCCAMMON, 2002), no estudo de doencas como o HIV (LINS et al., 1999).
Em engenharia elas sao usadas no estudo de resistencia de materiais (HEINO et al., 1998)
e no estudo de friccao e lubrificacao (GRANATO et al., 1996). Para citar apenas algumas
areas.
Neste capıtulo sao apresentados os fundamentos da Simulacao de Dinamica Molecular
atraves de um modelo simples que considera as partıculas como pontos de massa, quimi-
camente inertes, de estrutura interna ignorada e que sao tratadas pela mecanica classica.
Esse modelo, embora limitado, tem muito em comum com modelos mais elaborados (RA-
PAPORT, 1995) e para um estudo qualitativo tem se mostrado satisfatorio.
2.1 Potencial Intermolecular
O calculo das trajetorias das partıculas depende do potencial entre elas. Neste texto o
potencial tratado dependera apenas da distancia entre as partıculas, o que leva a seguinte
expressao para energia potencial U :
U = u(r12) + u(r13) + ... + u(r23) + ... =N−1∑i=1
N∑j=i+1
u(rij) (2.1)
em que N e o numero de partıculas e rij e a distancia entre as partıculas i e j.
A interacao entre um par de partıculas e caracterizado por uma forte repulsao a curta
distancia devido ao princıpio da exclusao de Pauli, e uma fraca atracao a partir de uma
certa distancia, em razao do chamado potencial de van der Waals. A forma exata escolhida
23
Figura 2.1 - Potencial de Lennard-Jones.
para o potencial deve levar em consideracao o tipo de fenomeno a ser simulado. Uma
abordagem possıvel para essa interacao e o potencial de Lennard-Jones (RAPAPORT, 1995):
u(r) = 4ε
[(σ
r
)12
−(σ
r
)6]
(2.2)
que e parametrizado pela distancia σ e pela energia ε, como pode ser visto na Figura (2.1):
As variaveis envolvidas nas simulacoes de dinamica molecular nas unidades de medida
do Sistema Internacional (SI) sao bastante pequenas, por exemplo, um valor tıpico para
duracao da simulacao e 10−11s a 10−9s (GOULD; TOBOCHNIK, 2003). O uso de unidades
adimensionais baseadas na escolha de σ como unidade de comprimento, m como unidade
de massa e ε como unidade de energia resulta na simplificacao das equacoes de movimento
e na capacidade de se escalar facilmente para unidades convenientes ao problema.
Em razao da natureza de curto alcance do potencial de Lennard-Jones (ele e praticamente
zero a uma distancia r > 3σ), pode-se definir u(r) = 0 quando r > rc, para um rc
conveniente. Essa estrategia diminui a quantidade de calculos necessarios a simulacao,
pois esse raio normalmente cobre uma area bastante menor que o tamanho total da area
de simulacao.
A forca f produzida entre cada par de partıculas e dada por:
f(rij) = −∇u(rij) =24ε
rij
[2
(σ
rij
)12
−(
σ
rij
)6]
rij (2.3)
24
em que rij e o versor na direcao ij.
2.2 Integracao das Equacoes de Movimento
Da Equacao (2.3) pode-se calcular a forca que resulta da interacao entre duas partıculas.
A forca resultante sobre uma partıcula qualquer e obtida computando-se par a par a
interacao da partıcula em questao e todas as outras que estejam em seu raio de acao (rc). A
segunda lei de Newton e entao usada para calcular a aceleracao a. A velocidade pode entao
ser obtida atraves da equacao diferencial dv/dt = a (em uma dimensao para simplificar), e
a nova posicao, atraves de dx/dt = v. Essas equacoes podem ser calculadas numericamente
pelo metodo de diferencas finitas. Dois esquemas muito comuns em Dinamica Molecular
sao o metodo de Verlet e o metodo Leap-Frog.
O metodo de Verlet pode ser deduzido a partir da serie de Taylor:
x(t + ∆t) = x(t) + ∆tx(t) + (∆t2
2)x(t) + O(∆t3)
Somando-se a expansao de x(t−∆t) da equacao acima obtem-se a expressao para posicao:
x(t + ∆t) = 2x(t)− x(t−∆t) + ∆t2x(t) + O(∆t4)
O erro e da ordem O(∆t4), pois o termo em ∆t3 e cancelado na soma. A velocidade e
obtida subtraindo-se x(t + ∆t) de x(t−∆t):
x(t) = [x(t + ∆t)− x(t−∆t)]/2∆t + O(∆t2)
Uma expressao de ordem superior pode ser obtida para velocidade, mas raramente e
necessaria.
O metodo Leap-Frog, tambem chamado de metodo half-step (GOULD; TOBOCHNIK, 2003),
tambem pode ser deduzido da serie de Taylor atraves do seguinte rearranjo da serie ori-
ginal:
x(t + ∆t) = x(t) + ∆t[x(t) + (∆t/2)x(t)] + O(∆t3)
O termo x(t)+ (∆t/2)x(t) pode ser escrito, tambem atraves de Taylor, como x(t+∆t/2),
o que fornece a expressao para a posicao:
x(t + ∆t) = x(t) + ∆tx(t + ∆t/2)
Velocidade e conseguida da subtracao das expansoes de x(t − ∆t/2) e x(t + ∆t/2), que
resulta em:
25
x(t + ∆t/2) = x(t−∆t/2) + ∆tx(t)
O metodo Leap-frog tem esse nome em razao de que posicoes e velocidades serem cal-
culados em tempos diferentes, aos saltos. Para obter a velocidade no mesmo instante da
posicao pode-se usar a correcao:
x(t) = x(t−∆t/2) + x(t)∆t/2
Ambos os metodos garantem uma boa conservacao de energia em relacao a metodos mais
sofisticados (RAPAPORT, 1995).
2.3 Condicoes de Contorno
Em um sistema real normalmente apenas uma fracao das moleculas estao em contato com
as paredes do recipiente que o contem, e, apesar do aumento da capacidade de proces-
samento dos computadores, simulacoes de moleculas so podem conter um numero relati-
vamente pequeno delas. Isso leva ao problema de como simular as paredes do recipiente,
pois se o sistema real for imitado com a quantidade pequena de partıculas que podem ser
simuladas, a maioria delas estara em contato com as paredes e os resultados da simulacao
nao corresponderao as interacoes do sistema em si, mas das partıculas e as paredes do
recipiente.
Uma abordagem possıvel e eliminar completamente as paredes do recipiente atraves da
hipotese de condicao de contorno periodica, em que uma partıcula que saia por uma de
suas bordas entre novamente na regiao de simulacao pelo lado oposto, como na Figura
2.2:
Em uma regiao de simulacao de comprimento L, o maximo afastamento entre duas partı-
culas e L/2, isso deve ser levado em conta durante o calculo das forcas. A integracao das
Figura 2.2 - Condicao de contorno periodica.
26
equacoes de movimento tambem consideram a condicao de contorno periodica durante o
movimento das partıculas.
Uma segunda possibilidade para a questao da condicao de contorno e eliminar do sistema
as partıculas que escapem pelas bordas como em (MERIMAA et al., 2000), algo que e
conhecido como condicao livre de contorno. Esse tipo de condicao de contorno e usada
para estudar a interacao entre o sistema e o ambiente exterior, aquecimento ou mudanca
de fase (WANG, 2002).
2.4 Algoritmo Basico de Simulacao de Dinamica Molecular
Em termos gerais o algoritmo de simulacao de dinamica molecular pode ser descrito com
o seguinte pseudo-codigo:
inicializac~ao
para cada timestep faca
para cada particula faca
calculo das forcas resultantes
2a lei de Newton para obter a acelerac~ao
integrac~ao para atualizar velocidades
integrac~ao para atualizar posic~oes
realizac~ao de medic~oes
fim para
fim para
Na Inicializacao sao ajustadas as posicoes e velocidades iniciais de cada partıcula. Uma
possibilidade para isso e dispor as partıculas regularmente espacadas entre si com as
direcoes das velocidades escolhidas aleatoriamente (mantendo-se o centro de massa es-
tacionario) e com magnitude correspondente a temperatura desejada. A temperatura T
de um conjunto de partıculas pode ser obtido das suas velocidades atraves da Expressao
(2.4).
T =1
dNk
N∑i=1
mivi(t)2 (2.4)
em que k e a constante de Boltzmann, N o numero de partıculas de massa m, em um
tempo t qualquer para um sistema de d dimensoes (GOULD; TOBOCHNIK, 2003). A fim de
27
ajustar o sistema de partıculas a uma temperatura desejada pode-se usar um fator f de
reescalamento das velocidades dado por:
T ′ =1
dNk
N∑i=1
mi[vi(t)f ]2
f =
√dNkT ′∑N
i=1 mivi(t)2
(2.5)
Esse metodo tambem pode ser usado durante a simulacao para garantir temperatura
constante. Outra forma de manter a temperatura constante e apresentado em (STEPHANY
et al., 2003) mas usa um metodo estocastico para isso.
O calculo das forcas depende do potencial escolhido para modelar o sistema. O potencial
de Lennard-Jones e apropriado para simular gases nobres e sistemas cuja substancia nao
e especificada (RAPAPORT, 1995). Partıculas eletricamente carregadas interagem atraves
do potencial de Columb, que e um potencial de longo alcance. Ha sistemas tambem em
que estao presentes interacoes de longo e curto alcances, como as simulacoes de ıons
(HOCKNEY; EASTWOOD, 1988).
Dado o potencial, a forca pode ser calculada como f = −∇u(r). Para o potencial de
Lennard-Jones esse gradiente resulta na Equacao (2.3) vista na Secao 2.1.
Como descrito na Secao 2.2, e necessaria a escolha de um metodo numerico para se calcular
velocidades e posicoes. Esse metodo deve gerar uma solucao estavel e garantir estabilidade
da energia. Alem de Verlet e Leap-Frog, a literatura documenta outros metodos para
integracao das equacoes de movimento, como por exemplo metodo predictor-corrector
(GOULD; TOBOCHNIK, 2003) e (RAPAPORT, 1995).
A ligacao entre as informacoes em nıvel microscopico fornecidas pela Simulacao de Dina-
mica Molecular e as propriedades macroscopicas do sistema e feita pela mecanica esta-
tıstica. Sistemas identicos apresentam propriedades como temperatura ou energia iguais
entre si, mesmo que as trajetorias das partıculas que os constitui sejam bem diferentes.
Essa relacao e compreendida atraves do conceito de medias estatısticas independentes do
tempo.
28
O estado termodinamico de um sistema pode ser descrito por um conjunto pequeno de
variaveis macroscopicas, como temperatura, pressao e numero de partıculas. As demais
propriedades podem ser derivadas daquelas. Em nıvel atomico o sistema pode ser descrito
em termos das posicoes (coordenas x, y, z) e seus momenta (nas direcoes x, y e z). Para
um sistema com N partıculas tem-se entao 6N variaveis que descrevem completamente o
sistema em nıvel atomico. Essas variaveis representam coordenadas em um espaco multidi-
mensional chamado espaco de fase. Todos os pontos desse espaco que satisfacam alguma
condicao termodinamica fazem parte de um mesmo ensemble, ou seja, um ensemble e
o conjunto de todas as configuracoes microscopicas possıveis do sistema para um dado
estado termodinamico. Alguns exemplos de ensembles sao:
• Ensemble Microcanonico: e caracterizado por um numero fixo de partıculas e
volume e energia fixos.
• Ensemble Canonico: e caracterizado por um numero fixo de partıculas e volume
e temperatura fixos.
• Ensemble Isobarico-Isotermico: e caracterizado por um numero fixo de partıculas
e pressao e temperatura fixos.
• Ensemble Gra-Canonico: e caracterizado por potencial quımico, volume e tem-
peratura fixos.
A simulacao de dinamica molecular gera pontos do espaco de fase, ou seja, uma evolucao
temporal de um ponto escolhido na etapa de inicializacao do programa. Ela nao pode gerar
todos os pontos do espaco de fase que pertencem a um ensemble, mas se o intervalo de
tempo for suficientemente longo a simulacao podera obter uma conjunto representativo
do ensemble. Desta forma uma propriedade qualquer do ensemble tambem podera ser
observada nos dados gerados pela simulacao.
Um exemplo media temporal e a media da energia cinetica K que pode ser calculada
como:
K = 〈K〉 =1
M
M∑j=1
N∑i=1
mi
2vi · vi (2.6)
em que M e o numero de passos de tempo, N , o numero de atomos, mi e vi a massa e a
velocidade da partıcula i.
29
Tabela 2.1 - Tempos das principais funcoes de uma simulacao de DM.
% self self totaltime seconds calls us/call name99.10 57.41 5000 11482.00 ComputeForces0.29 0.17 5000 34.00 LeapfrogStep0.29 0.17 5000 34.00 EvalProps0.26 0.15 5000 30.00 ApplyBoundaryCond
2.5 Consideracoes sobre Complexidade Algorıtmica
A quantidade de partıculas simuladas influencia a precisao das medicoes realizadas, uma
quantidade pequena de partıculas aumenta as flutuacoes nos resultados (RAPAPORT,
1995). Entretanto, limitacoes de hardware impedem que se aumente indefinidamente o
numero de partıculas.
Em um codigo de dinamica molecular o trecho que mais consome tempo e o calculo das
forcas, como pode ser visto naprimeira linha da Tabela (2.1) gerada pelo utilitario gprof
a partir do exemplo da pagina 23 de (RAPAPORT, 1995) para uma simulacao de 20 × 20
celulas, 400 atomos, densidade 0.8, passo de tempo (∆t) 0.005 e 100 timesteps1.
Nesse exemplo e calculada a interacao de cada partıcula com todas as outras. Usa-se a
terceira lei de Newton para reduzir a quantidade de calculos. Ainda assim esse algoritmo
tem complexidade N2. E claro que para interacoes de curto alcance essa abordagem e
bastante ineficiente.
Um segundo metodo, que aproveita o curto alcance do potencial, e o metodo de divisao
por celulas, que consiste em dividir a area de simulacao de lado L em celulas cujos lados
excedem o raio de corte rc, normalmente dL/rce. Desta forma e garantido que todas as
interacoes em relacao a uma partıcula qualquer ficam restritas a celula em que ela reside
e as celulas adjacentes. A Figura (2.3(b)) ilustra esse metodo.
Percorrendo-se celula a celula da esquerda para a direita e de cima para baixo, e usando-se
a terceira lei de Newton, as celulas que devem ser examinadas para uma dada partıcula
tem a forma da area hachurada da Figura (2.3(b)) para duas dimensoes. A complexidade
desse algoritmo e linear como demonstrado em (TRAVIESO; SLEATS, 1992).
Nao e necessario que a largura das celulas exceda o raio de corte, entretanto uma largura
1Codigo executado em um Pentium III 550MHz, 192MB RAM.
30
(a) Todos os pares (b) Divisao por celulas (c) Lista de vizinhos
Figura 2.3 - Metodos de calculo das forcas.
menor obriga que mais celulas, alem das adjacentes, sejam consideradas. Por outro lado
em baixas densidades, como uma densidade abaixo de um (RAPAPORT, 1995), a largura
das celulas podem ser maiores que dL/rce.
O metodo de divisao por celulas, embora seja eficiente, examina, para cada partıcula, mais
pares do que o necessario. Em duas dimensoes a razao e de π/9 e em tres dimensoes e de
4π/81. O metodo de lista de vizinhos e usado para diminuir essa computacao desnecessaria.
Ele consiste em manter para cada partıcula uma lista de pares que estao a uma distancia
menor que rn = rc + ∆r. Essa lista e usada na computacao das forcas e sua atualizacao
ocorre apos um certo numero de iteracoes, que depende de parametros como densidade
e temperatura, e reflete a chance de uma partıcula que nao esteja na lista se mover uma
distancia ∆r e entrar na regiao de interacao. ∆r normalmente e pequeno em relacao a rc
(RAPAPORT, 1995), o que justifica o uso desse metodo. Divisao por celulas e usada para a
atualizacao das listas, entretanto em sistemas pequenos o metodo de todos os pares pode
ser usado.
31
3 PROCESSAMENTO PARALELO
O interesse por problemas cada vez mais complexos (GRAND. . . , 2004) tem levado a ne-
cessidade de computadores mais e mais potentes para resolver-los. Entretanto limitacoes
fısicas e economicas tem restringido o aumento da velocidade dos computadores sequen-
ciais, ou seja, computadores que executam instrucoes em serie, uma apos a outra pela
UCP (Unidade Central de Processamento). Por outro lado, problemas computacionais
usualmente podem ter algumas de suas partes dividida em pedacos que poderiam ser so-
lucionados ao mesmo tempo, ou processadas em paralelo. Processamento paralelo e entao
uma forma pela qual a demanda computacional e suprida atraves do uso simultaneo de
recursos computacionais como processadores para solucao de um problema.
Neste capıtulo serao apresentados conceitos basicos a respeito de arquiteturas paralelas,
particionamento da computacao, modelos de programacao, ferramentas de programacao
paralela, enfatizando-se MPI, e metricas de desempenho.
3.1 Arquiteturas de Computadores Paralelos
Uma maneira classica de se classificar arquiteturas de computadores e pela forma que o
fluxo de instrucoes e os dados se apresentam. Essa classificacao e conhecida por taxono-
mia de Flynn (FLYNN, 1972) e, como observa (TANENBAUM, 2001), e um tanto grosseira,
principalmente em razao do surgimento de novas arquiteturas que nem sempre sao fa-
cilmente acomodadas nas classes existentes (DUNCAN, 1990) ou em razao de um grande
numero de arquiteturas, mesmo com caracterısticas bem diferentes, serem agrupadas como
um mesmo tipo, como e o caso da classe MIMD. A taxonomia de Flynn abrange quatro
classes de arquiteturas:
• SISD (Single Instruction Single Data): Fluxo unico de instrucoes sobre um unico
conjunto de dados.
• SIMD (Single Instruction Multiple Data): Fluxo unico de instrucoes em multiplos
conjuntos de dados.
• MISD (Multiple Instruction Single Data): Fluxo multiplo de instrucoes em um
unico conjunto de dados.
• MIMD (Multiple Instruction Multiple Data): Fluxo multiplo de instrucoes sobre
multiplos conjuntos de dados.
A arquitetura do tipo SISD e a arquitetura de Von Neumann, em que o registrador de
endereco de instrucao (PC - Program Counter) garante a execucao sequencial de um con-
33
junto de instrucoes sobre um unico conjunto de dados presentes na memoria (GODFREY;
HENDRY, 1993). Os computadores domesticos e estacoes de trabalho atuais incluem uma
serie de otimizacoes que permitem um pequeno grau de paralelismo na execucao de ins-
trucoes, entretanto mesmo esses computadores devem ser classificados como SISD, pois
esses recursos sozinhos nao representam base para desenvolvimento de solucoes paralelas
de alto-nıvel (DUNCAN, 1990).
Computadores classificados como SIMD sao normalmente empregados na resolucao de
problemas em que os dados sao estruturados em vetores e matrizes. Maquinas desse tipo
possuem uma unidade de controle que executa a mesma instrucao sobre um conjunto de
dados de uma unica vez. Essas maquinas tambem sao conhecidas como computadores
vetoriais e como o custo delas e bastante elevado, sua aplicacao normalmente e restrita.
Algumas maquinas do tipo SISD tambem possuem estruturas semelhantes as encontradas
em computadores vetoriais (em escala bastante menor), como exemplo, encontra-se em
processadores Intel R© e AMD R© um conjunto de instrucoes conhecidas como MMX e SSE
que operam sobre registradores que sao pequenos vetores.
A arquitetura MISD deveria ter multiplos processadores aplicando diferentes instrucoes
sobre o mesmo conjunto de dados, mas parece nao haver representantes desse tipo de
arquitetura.
A arquitetura MIMD classifica computadores que possuem multiplos processadores execu-
tando instrucoes diversas em dados diversos autonomamente. Essa e a arquitetura de com-
putadores paralelos mais comuns, tao comum que abrange uma variedade muito grande
de computadores e pode ser sub-dividida, sob o criterio de configuracao da memoria, em
maquinas de memoria compartilhada e maquinas de memoria distribuıda.
A arquitetura UMA (Uniform Memory Access) abrange computadores que compartilham
memoria e tem espaco de enderecamento unico. O compartilhamento da memoria e feito
atraves de um barramento (AOYAMA; NAKANO, 1999) como ilustrado na Figura (3.1).
Apenas um processador de cada vez tem acesso ao barramento, e sendo assim, um pro-
cessador que queira usar a memoria enquanto outro a esteja usando tem de esperar. A
fim de reduzir a ocorrencia desse tipo de contencao, foi incluıda nessas maquinas uma
memoria pequena e rapida chamada cache, posta entre cada processador e o barramento,
que armazena as ultimas referencias a memoria principal. Dessa forma, dados constan-
temente usados podem ser acessados sem uso do barramento. A memoria cache tambem
esta presente em maquinas SISD para diminuir o tempo de acesso a dados constantemente
usados, pois a velocidade de acesso a cache e maior que a da memoria principal.
34
Figura 3.1 - Uniform Memory Access.
A comunicacao entre processadores nesse tipo de computador e bastante rapido, entretanto
a quantidade de processadores numa maquina nao pode ser facilmente aumentada. Se
existir uma unica imagem do sistema operacional gerenciando todo o computador UMA,
esse tipo de maquina e tambem chamado de SMP ou multi-processador simetrico.
A arquitetura NUMA ou de acesso nao uniforme a memoria (Non-Uniform Memory Ac-
cess) e caracterizada por memoria fisicamente distribuıda, mas logicamente compartilhada.
Cada processador possui uma memoria local, mas pode acessar de forma transparente as
memorias dos outros processadores. O acesso remoto, entretanto, nao e tao rapido quando
o acesso local.
Computadores de memoria distribuıda ou multi-computadores sao formados por um con-
junto de computadores autonomos, os nos, ligados entre si atraves de uma rede de interco-
nexao. Cada no do multi-computador e um computador independente, como uma maquina
SISD, com sua propria memoria e sub-sistema de entrada e saıda (E/S) locais, como mos-
tra a Figura (3.1). Alguns autores (TANENBAUM, 2001) (PFISTER, 1998) ainda costumam
sub-classificar os multi-computadores em cluster de estacoes de trabalho e MPP (Mas-
sively Parallel Processors). A diferenca basica entre essas duas classes de computadores
reside no custo de montagem delas e no poder de processamento, a primeira, pode ate
mesmo ser montada com componentes comerciais (off-the-shelf ), tendo um custo e um
poder de processamento inferior a segunda.
E importante observar que apenas se ter um conjunto de computadores ligados em rede nao
os torna um computador paralelo, sendo assim parece conveniente adotar como criterio
de classificacao o objetivo do sistema montado. Se o objetivo for tratar um problema
que tenha sido decomposto para que cada uma de suas partes seja resolvida por um dos
35
Figura 3.2 - Exemplo de Multi-computador.
computadores da rede, entao o conjunto das maquinas representa um multi-computador.
Toda a comunicacao entre processadores de um multi-computador e realizado atraves da
rede de interconexao, que tem um tempo de acesso superior ao da memoria, principal-
mente em clusters de estacoes de trabalho. Normalmente, para diminuir o impacto desse
tempo no total gasto, o sistema operacional programa a comunicacao atraves da DMA
(Direct Memory Access), que normalmente esta disponıvel nos nos do multi-computador.
A aplicacao pode entao continuar o processamento (nao bloquear) enquanto a comuni-
cacao e feita. E importante salientar que embora o processador fique livre enquanto a
comunicacao e feita atraves da DMA, o barramento pode estar sendo usado, o que im-
pede, por exemplo que o processador acesse a memoria principal, o que caracteriza o que
e chamado de roubo de ciclos (TANENBAUM, 2001).
Alguns computadores podem ainda ser classificados como hıbridos, como por exemplo, se
pode montar um multi-computador em que cada no e uma maquina UMA, e cada um dos
processadores da maquina UMA ser vetorial, como e o caso da maquina SX-6 da Nec R©.
Embora nao seja exatamente uma arquitetura de computadores, grades computacionais
(grids) tem surgido como uma abordagem para processamento de alto desempenho, em-
bora tambem nao tenha como unico objetivo poder de processamento. Grades computaci-
onais consiste em uma infra-estrutura de hardware e software que prove acesso confiavel,
consistente e barato a recursos computacionais de alto desempenho que estao distribuıdos
fisicamente (FOSTER; KESSELMAN, 1999). Espera-se que no futuro arquiteturas avancadas
de computadores estejam disponıveis a baixo custo atraves de uma rede como a internet
assim como hoje informacoes estao disponıveis atraves da World Wide Web.
36
3.2 Particionamento do Problema
Particao do problema e a forma como e dividida a computacao, necessaria para se resol-
ver um problema, em um computador paralelo. Existem basicamente duas formas de se
particionar um problema (FOSTER, 1995):
• Particao de domınio: processadores diferentes executam as mesmas tarefas em
dados diferentes.
• Particao de tarefas ou decomposicao funcional: processadores diferentes execu-
tam tarefas diferentes
Na particao de domınio, os dados do problema sao divididos entre os processadores, que
executam as mesmas tarefas sobre os dados que lhes cabem. No particionamento de ta-
refas, as rotinas que compoe a solucao sao executados por processadores diferentes. Uma
abordagem hıbrida combinando as duas formas de particionamento tambem e possıvel.
Um dos criterios para maximizacao do uso da maquina paralela no que diz respeito a parti-
cao do problema e o balanceamento de carga, que e a distribuicao uniforme da quantidade
de computacao entre os processadores disponıveis.
3.3 Modelos de Programacao Paralela
O principal objetivo na escrita de um programa paralelo e a utilizacao de varios pro-
cessadores para diminuicao do tempo gasto pelo programa. Existem diversos modelos
de programacao paralela que de varias formas instrumenta o programador a atingir esse
objetivo. A seguir descreve-se apenas dois modelos: fork-join e troca de mensagens.
O modelo Fork-Join e baseado na criacao de tarefas para execucao em paralelo nos diver-
sos processadores do computador. Ele foi inicialmente criado para especificar concorrencia
(CONWAY, 1963) (DENNIS; HORN, 1966). No padrao Posix, a primitiva fork e executada
por um processo para a criacao de varios processos filhos, cada um pode executar parte
da computacao, nao necessariamente em processadores diferentes. Uma vez que se tenha
terminado o processamento, o processo pai executa a primitiva join para juntar os proces-
sos. A comunicacao e feita por mecanismos de IPC (Interprocess Communication), como
memoria compartilhada e semaforos. A Figura 3.3(b) ilustra esse modelo.
E importante observar que alguns trechos de um programa sao inerentemente sequenciais
e nao podem se beneficiar da quantidade de processadores do computador paralelo, na
Figura 3.3(b) esses trechos sao nomeados por S1 e S2.
37
(a) Sequencial (b) Fork-Join
Figura 3.3 - Modelos de programacao.
Figura 3.4 - Modelo de programacao por troca de mensagens.
Processos leves ou threads representam uma melhor escolha para o modelo Fork-Join,
pois a criacao e o escalonamento de processos completos sao mais custosos. Diferente
dos processos, threads compartilham o mesmo espaco de enderecamento, o que elimina a
necessidade de comunicacao por mecanismos de IPC.
Em computadores com memoria distribuıda, cada processador tem de enviar explicita-
mente os dados que quer compartilhar, ao mesmo tempo que o processador destinatario
tem de esperar pelo dado. Esse modelo e conhecido como modelo de programacao por
troca de mensagens. A Figura (3.3) ilustra esse modelo.
Deve-se observar da Figura (3.3) que o tempo dos trecho P1 a P4 foram aumentados em
38
Figura 3.5 - Comparacao entre memoria compartilhada e rede Gigabit Ethernet.
relacao ao sequencial (3.3(a)) para enfatizar o tempo gasto em comunicacao, que nao existe
no programa sequencial. O tempo de envio de uma mensagem (Tmsg) depende basicamente
de dois fatores: o tempo de inıcio da comunicacao (ts) e o tempo de transferencia por
palavra enviada (tw), como pode ser visto na Equacao 3.1, em que L e a quantidade de
palavras da mensagem. Embora esse modelo seja bastante simplificado ele fornece uma
forma simples de comparacao entre formas de conexao entre processadores. A Figura
3.3 mostra isso com uma comparacao entre comunicacao entre processadores atraves de
memoria compartilhada, mas usando passagem de mensagens, e atraves de uma rede
Gigabit Ethernet, esse figura ilustra a performance inferior da comunicacao atraves da
rede Gigabit Ethernet em relacao a memoria compartilhada. Um modelo mas completo
para custo da comunicacao pode ser encontrado em (FOSTER, 1995).
Tmsg = ts + tw ∗ L (3.1)
Como ilustrado na comparacao acima, o tempo de comunicacao atraves da rede de in-
terconexao e maior do que o de acesso a memoria em computadores UMA, isso leva a
uma preocupacao por parte dos programadores em diminuir a quantidade de comunica-
coes em relacao a quantidade de processamento em um programa, ou, em outras palavras,
aumentar a granularidade do processamento.
Vale ressaltar que, embora normalmente o modelo de troca de mensagens seja usado
39
em arquiteturas de memoria distribuıda, nao existe nenhuma restricao ao seu uso em
computadores de memoria compartilhada. E possıvel tambem uma abordagem hıbrida,
em multi-computadores em que os nos sao maquinas UMA.
3.4 Ferramentas de Programacao Paralela
Existem varias linguagens e ferramentas de programacao destinadas a programacao pa-
ralela. Exemplos delas sao HPF, OpenMP, PVM e MPI. Abaixo descreve-se brevemente
as tres primeiras e no sub-topico seguinte, em mais detalhes, o MPI, que foi usado nesse
trabalho.
HPF (High Performance Fortran) e formado por extensoes ao Fortran 90 para imple-
mentar paralelismo de dados, ou seja, a concorrencia que e obtida quando as mesmas
operacoes sao aplicadas por processadores diferentes em suas partes do domınio. Diretivas
estao disponıveis no HPF para indicar ao compilador como distribuir os dados. Existem
implementacoes para arquiteturas de memoria compartilhada e memoria distribuıda, essa
ultima podendo ser inclusive implementada como chamadas MPI.
A biblioteca PVM de troca de mensagens tem como objetivo a criacao de uma maquina
multiprocessada virtual atraves de um conjunto de computadores ligados em rede, po-
dendo inclusive ser de arquiteturas diferentes (heterogeneas) (DOWD; SEVERANCE, 1998).
Ele e composto de uma biblioteca, que inclui rotinas para envio de mensagens, criacao de
processos, coordenacao e modificacao da maquina virtual, e um deamon que executa em
todos os computadores da maquina virtual (GEIST et al., 1994).
OpenMP e um padrao portavel para escrita de programas multithread composto de um
conjunto de diretivas e uma biblioteca de rotinas. A paralelizacao do codigo e feita incre-
mentalmente atraves da adicao de diretivas que durante a compilacao orientam o compi-
lador onde threads devem ser criadas e reunidas.
3.4.1 A Biblioteca de Comunicacao MPI
A necessidade de padronizacao em ambientes de passagem de mensagem levou a criacao do
MPI (Message-Passing Interface), que e um esforco de diversos fabricantes de hardware,
desenvolvedores de software e cientistas no sentido de criar uma interface padronizada
de troca de mensagens. Atualmente existem diversas implementacoes do MPI, como o
LAM/MPI e o MPICH.
Os objetivos do padrao MPI (MPI. . . , 1994) sao: portabilidade; projeto da interface de pro-
gramacao, nao a sua implementacao; comunicacao eficiente e confiavel; a implementacao
40
do padrao deve funcionar em ambientes heterogeneos; embora deva existir a ligacao entre
a interface e as linguagens C e Fortran, o padrao deve ser semanticamente independente
da linguagem; o padrao deve ser semelhante as bibliotecas ja existentes, como PVM; a
interface deve ser projetada para permitir thread-safety.
As principais funcionalidades providas pelo MPI sao: suporte a grupo de processos e a
contextos de comunicacao, comunicacao ponto-a-ponto, comunicacao coletiva, topologias
virtuais e gerencia e consulta do ambiente.
Na versao do MPI usada nesse trabalho (MPI-1), a criacao de processos fica a cargo do
usuario e a quantidade deles nao muda durante a execucao do programa paralelo. O padrao
abrange rotinas para criacao e gerencia de grupos de processos, cujo objetivo e auxiliar
na organizacao da execucao de sub-tarefas. Todas as comunicacoes feitas com o MPI sao
realizadas no contexto de um comunicador, que e formado por um grupo de processo
cada um dos quais identificados por um rank, que e um ındice da lista de processos do
comunicador.
As rotinas de comunicacao compoem o nucleo principal do MPI. Existem rotinas para
comunicacao ponto-a-ponto, que envolvem apenas um par de processos. Nesse tipo de
comunicacao um processo cujo rank seja A que queira enviar um conjunto de dados para
um outro processo cujo rank seja B, deve chamar uma rotina para enviar uma mensagem
para B contendo o conjunto de dados, por exemplo:
MPI_Send(&send_buffer, n, tipo_de_dado, B, rotulo, comm);
em que send buffer e um vetor contendo n elementos do tipo tipo de dado que devem ser
enviados para B atraves do comunicador comm, do qual A e B fazem parte. rotulo serve
para identificar diferentes mensagens vindas do mesmo processo, nesse caso o processo
A. O processo B, por sua vez, deve chamar uma rotina de recebimento, a exemplo da
seguinte chamada:
MPI_Recv(&recv_buffer, n, tipo_de_dado, A, rotulo, comm, &status);
que indica que o processo B esta esperando de A um conjunto de ate n elementos do
tipo tipo de dado, identificado com rotulo. Existem outras rotinas dentro do pacote MPI
41
para envio de mensagens: para lidar com mensagens sıncronas, com buffer gerenciado
pelo usuario, quando e assumida que a chamada de recebimento ja foi realizada. Para
aumentar a performance em alguns programas paralelos, pode-se chamar essas rotinas em
modo nao-bloqueado, o que permite uma sobreposicao de comunicacao e processamento.
Nesse modo as chamadas das rotinas retornam antes de sua finalizacao, permitindo que
outros processamentos sejam realizados enquanto se espera, entretanto e assumido que o
hardware subjacente pode executar a comunicacao autonomamente.
Comunicacao coletiva permite enviar mensagens de e para um grupo de processos, essas
mensagens podem basicamente ter objetivo de reducao, sincronizacao ou distribuicao de
dados. Em todas as formas de comunicacao coletiva todos os processos de um grupo
devem chamar a rotina para que ela nao falhe, se, por exemplo, em uma barreira pelo
menos um processador do grupo para o qual a barreira foi estabelecida nao chamar a
rotina correspondente, entao o ambiente gera um erro de execucao.
Topologias virtuais possibilitam que processos executando MPI formem estruturas topo-
logicas como arvores, aneis, grades, que podem se ajustar ao hardware subjacente.
O padrao MPI preve tambem rotinas para consultar o ambiente, um processo pode con-
sultar seu rank, que identifica unicamente um processador dentro de um comunicador,
ou quantos processos participam de qualquer comunicador. Por exemplo, um processa-
dor que queira saber qual e seu rank no comunicador MPI COMM WORLD, que e o
comunicador principal, pode executar:
MPI_Comm_rank(MPI_COMM_WORLD, &meu_rank);
para obter o numero de processadores no grupo do comunicador:
MPI_Comm_size(MPI_COMM_WORLD, &size);
A estrutura basica de um programa escrito com MPI tem a seguinte forma:
#include <mpi.h>
...
main(int argc, char **argv) {
42
...
MPI_Init(&argc, &argv);
...
MPI_Finalize();
...
}
As rotinas MPI Init inicia o ambiente MPI, enquanto que MPI Finalize o finaliza.
As demais chamadas as rotinas do MPI devem estar entre as chamadas MPI Init e
MPI Finalize.
A versao 2 do MPI encontra-se em desenvolvimento e permite novas funcionalidades,
como criacao dinamica de processos, operacao de entrada e saıda paralela, acesso remoto
a memoria e comunicacao coletiva nao-bloqueada, dentre outras.
3.5 Metricas de Desempenho
Speedup (S) e o termo que designa quao mais rapido um programa e executado usando-se
N processadores comparado com a performance em um unico processador. Ele e dado
por:
S =Ts
Tp
(3.2)
em que Ts e o tempo de execucao no processador sequencial e Tp, o tempo de execucao
nos N processadores.
Eficiencia (E) refere-se a fracao de tempo em processamento efetivo. E dado pela seguinte
relacao:
E =S
N(3.3)
Overhead da paralelizacao corresponde ao tempo gasto para coordenar os processadores
em uma computacao paralela, em oposicao ao tempo gasto em trabalho util. Ele inclui
normalmente:
• Inicializacao do ambiente
43
• Sincronizacao
• Comunicacao de dados
• Processamento redundante
• Finalizacao do ambiente
De maneira geral, diz-se que um programa paralelo e escalavel em funcao do numero de
processadores N quando o aumento de N implica em tempos de execucao ainda menores e
consequentemente speedups maiores (GRAMA et al., 1993). Entretanto esta escalabilidade
e limitada pela fracao sequencial (nao paralelizavel) do codigo. Enquanto o tempo de
execucao da fracao paralela do codigo diminui em funcao de N , o tempo de execucao da
fracao sequencial permanece constante, conforme expresso pela Lei de Amdahl (AMDAHL,
1967). Essa lei estabelece que o maximo speedup (S) possıvel para um numero infinito
de processadores, desconsiderando qualquer overhead da paralelizacao, e 1/s, em que s
representa a fracao sequencial do tempo de execucao. A Lei de Amdahl pode ser deduzida
da definicao de speedup (S), como pode ser visto na Equacao 3.4 para N processadores:
S = (s + p)/(s + p/N) = 1/(s + p/N) (3.4)
em que p refere-se a fracao paralelizavel do tempo de execucao total, de tal forma que
s + p = 1. Observa-se que quando N tende a infinito, S tende a 1/s. Por exemplo, a
aplicacao da Lei de Amdahl para N igual a 16, 32 e 64 processadores, quantidades comuns
em maquinas paralelas de memoria distribuıda de baixo custo, clusters de computadores,
leva a penalizacoes muito grandes no speedup mesmo para valores pequenos de s, conforme
ilustrado na Figura 3.5.
Resultados semelhantes sao apresentados em (GUSTAFSON, 1988), para 1024 processado-
res, os quais parecem contradizer resultados praticos tambem mostrados no mesmo artigo.
Face a essa discrepancia o autor apresenta uma alternativa a lei de Amdahl, que considera
que a fracao paralela nao e independente de N . Essa abordagem toma o caminho oposto
ao da Lei da Amdahl ao estimar qual seria o tempo de execucao de um programa para-
lelo com N processadores numa maquina sequencial para um dado tamanho do problema
considerado. Esse tempo e entao tomado como referencia na analise de escalabilidade em
funcao do numero de processadores. Esse tempo de execucao sequencial equivalente a exe-
cucao paralela com N processadores e dado por s + p ∗ N . E entao definido o chamado
scaled speedup (Sscaled), dado por:
44
Figura 3.6 - Speedup sob a perspectiva da lei de Amdahl.
Sscaled = (s + p ∗N)/(s + p) = s + p ∗N = N + (1−N) ∗ s (3.5)
Define-se em processamento paralelo a granularidade como sendo a razao entre computa-
cao e comunicacao. Quando se tem mais computacao do que comunicacao, algo desejavel,
diz-se que a granularidade e grossa, caso contrario a granularidade e dita fina.
45
4 MOTOR PARALELO PARA SIMULACAO DE DINAMICA MOLECU-
LAR
Nos capıtulos anteriores, foram abordadas as simulacoes de dinamica molecular e tambem
arquiteturas, modelos de programacao e ferramentas de computacao paralela. Este capı-
tulo trata do motor de simulacao, que e a parte do codigo de dinamica molecular referente
ao calculo das interacoes entre as partıculas do sistema simulado a cada timestep e a
correspondente atualizacao de suas posicoes e velocidades, sem incluir a visualizacao ou
qualquer tipo de interatividade com o usuario.
Neste trabalho, propoe-se uma abordagem para a paralelizacao do software de DM com
capacidade interativa de visualizacao ADKS, o qual sera detalhado na Secao 5.2. Neste
capıtulo detalha-se a paralelizacao proposta e implementada do motor de simulacao do
ADKS. Abordam-se aqui tambem aspectos gerais sobre paralelizacao de motor de simu-
lacao em DM.
4.1 A Demanda por Desempenho em Dinamica Molecular
Simulacoes de dinamica molecular sao computacionalmente pesadas em dois aspectos
- o numero de partıculas que sao simuladas e o numero de timesteps. Esses aspectos
sobrecarregam o processador, mas nao a memoria pois normalmente apenas informacoes
do estado atual do sistema sao armazenadas, como por exemplo as posicoes e velocidades
das partıculas num dado timestep (PLIMPTON, 1995).
Tipicamente, simulacoes de DM envolvem muitas milhares ou milhoes de partıculas, para
modelar apenas alguns pico-segundos de fenomenos numa escala sub-micron. Por exem-
plo, a quantidade de partıculas que compoe objetos macroscopicos e da ordem de 1020
por centımetro cubico (KATZ, 1967), o que torna inviavel sua simulacao. Como observado
por Rapaport em (RAPAPORT, 1995), o hardware impoe limitacoes na quantidade e com-
plexidade das partıculas simuladas por DM e sistemas de partıculas pequenos aumentam
as flutuacoes e impoem limites na precisao das medicoes. Os algoritmos de divisao por
celulas e lista de vizinhos apresentados no Capıtulo 2 sao empregados, mas normalmente
algoritmos paralelos sao mais apropriados para lidar com sistemas grandes. Entretanto,
ferramentas automaticas de paralelizacao nem sempre sao adequadas, seja por nao pro-
duzirem uma paralelizacao eficiente, seja por nao estarem disponıveis para a arquitetura
empregada. Sendo assim uma reestruturacao do codigo e normalmente necessaria para
entao se proceder a paralelizacao (RAPAPORT, 1995), definindo-se, por exemplo, explici-
tamente diretivas de comunicacao e sincronismo.
A ideia basica de paralelizacao pressupoe dividir a computacao em partes que podem ser
47
executadas concorrentemente pelos processadores, de forma a se obter um tempo menor
de execucao. Como discutido no Capıtulo 3, essa divisao pode ser feita pela decompo-
sicao funcional ou considerando-se a decomposicao do domınio. Simulacoes de DM com
potenciais de curto alcance apresentam dependencias de dados em volume pequeno, o que
permite o emprego do modelo de decomposicao do domınio.
4.2 Metodos para Paralelizacao em Dinamica Molecular
Existem basicamente duas classes de metodos para paralelizacao de algoritmos de Dina-
mica Molecular (PLIMPTON, 1995). A primeira classe e caracterizada pela determinacao
antecipada das forcas que cada processador ira calcular durante toda a simulacao, ou
seja, a atribuicao fixa do conjunto de interacoes entre partıculas que cada processador
tratara. Essa classe se assemelha a descricao lagrangeana dos escoamentos em mecanica
dos fluidos. Dois metodos encontrados em (PLIMPTON, 1995) pertencem a essa classe e
se caracterizam pela forma com que particionam o domınio do problema: o algoritmo de
decomposicao por atomos (atom-decomposition) e algoritmo de decomposicao por forcas
(force-decomposition).
No algoritmo de decomposicao por atomos as n partıculas que compoem o sistema sao dis-
tribuıdas entre os processadores da maquina paralela. Cada processador fica entao respon-
savel pelo calculo das forcas e atualizacao das velocidades e posicoes das suas partıculas.
Essa abordagem, apesar de simples, implica na necessidade de que todos os processadores
mantenham atualizadas as posicoes de todos os atomos, pois uma partıcula pode interagir
com outra que pode estar na memoria local de qualquer processador, dessa forma a com-
plexidade da comunicacao e O(n), o que para maquinas paralelas de memoria distribuıda
e comunicacao de alta latencia representa um custo alto.
A fim de melhorar a eficiencia da comunicacao, (PLIMPTON, 1995) propoe o algoritmo de
decomposicao por forcas. Nesse algoritmo cada processador e responsavel pelo calculo de
um bloco da matriz de forcas como visto na Figura 4.2, em que 16 processadores fazem
parte da computacao. Inicialmente cada processador possui as posicoes das partıculas
correspondentes indicadas pelos vetores x e x′ (por exemplo, o processador 10 tem as suas
partıculas e as partıculas dos processadores 8, 9, 11, 2, 6, 14). As forcas entre as partıculas
locais no vetor x e as partıculas locais no vetor x′ sao calculadas e compartilhadas entre
os processadores da mesma linha na figura (assim para o processador 10, o calculo das
forcas entre as partıculas de 8 e as de 2, 6, 10 e 14 sao enviadas para o processador 8).
Em seguida, as posicoes das partıculas do processador sao atualizadas e compartilhadas
com os processadores da linha e da coluna a fim de recompor os trechos dos vetores x
e x’, reiniciando o ciclo. Sendo assim a complexidade da comunicacao fica reduzida a
48
Figura 4.1 - Matriz de forcas.
O(n/√
N).
A eficiencia da computacao dos algoritmos acima pode ser melhorada pelo emprego de
esquemas tais como lista de vizinhos ou divisao por celulas, o que reduz a complexidade
da computacao para O(n/N), para N processadores. Entretanto, esses algoritmos nao
escalam bem como observado por (RAPAPORT, 1995) e (BRUNNER, 2000).
A segunda classe de metodos para paralelizacao de algoritmos de DM se assemelha a
descricao euleriana dos escoamentos em mecanica dos fluidos. Sao atribuıdas regioes do
espaco (domınio de simulacao) a cada processador, e sendo assim, as partıculas podem
migrar de um processador a outro durante a simulacao. Em (PLIMPTON, 1995), e apre-
sentado um algoritmo dessa classe, chamado algoritmo de decomposicao espacial (space
decomposition), em que o espaco de simulacao e dividido em volumes tridimensionais, di-
vididos entre os processadores da maquina paralela. Cada processador e responsavel pelo
calculo das interacoes entre as partıculas de seu espaco local, inclusive das interacoes com
as partıculas dos espacos vizinhos, atribuıdos a outros processadores. Uma vez calculadas
as forcas, e feita a atualizacao das velocidades e posicoes. Uma verificacao de posicao de-
termina as partıculas que devem migrar de um processador a outro. A comunicacao nesse
algoritmo fica restrita as partıculas que migram entre processadores e as partıculas das
bordas de cada espaco local, que nao migram, mas sao usadas no calculo das forcas por
outros processadores. Como a quantidade de partıculas migrantes e inferior ao numero de
partıculas nas bordas (PLIMPTON, 1995) e cada borda tem pelo menos a largura da dis-
tancia de corte rc, entao a comunicacao e proporcional a casca de espessura rc que envolve
49
Figura 4.2 - Decomposicao em cubos.
a regiao do espaco de cada processador. No caso do domınio tridimensional de dimensoes
L × L × L e decomposicao em cubos iguais em volume, supondo densidade constante
ρ = n/L3 = 1, cada cubo tera aresta l = (n/N)1/3 e consequentemente o volume da casca
sera 6 ∗ rc ∗ (n/N)2/3 (Figura 4.2), logo a complexidade da comunicacao e O((n/N)2/3). A
computacao e proporcional a O(n/N), tambem supondo densidade constante (TRAVIESO;
SLEATS, 1992).
O algoritmo de decomposicao espacial foi usado no presente trabalho, uma vez que apre-
senta pequena comunicacao em comparacao aos outros algoritmos, algo que e importante
para a arquitetura usada. Alem disso esse abordagem escala bem com o numero de ato-
mos e de processadores como observado em (RAPAPORT, 1995) e (BRUNNER, 2000) e sua
implementacao e mais direta quando se trata de paralelizar um codigo sequencial que usa
divisao por celulas, como e o caso do software ADKS usado neste trabalho como estudo
de caso.
4.3 Arquitetura Empregada
O algoritmo de DM empregado neste trabalho foi otimizado para uma arquitetura pa-
ralela de memoria distribuıda, sendo alguns aspectos caracterısticos dessa arquitetura
comentados a seguir.
Arquiteturas paralelas com processadores vetoriais ou maquinas multiprocessadas com
um grande numero de processadores nao sao amplamente disponıveis, exceto para aplica-
coes especıficas. Por outro lado, maquinas paralelas de memoria distribuıda constituıdas
por computadores amplamente disponıveis comercialmente, os chamados clusters, tem se
difundido grandemente como uma alternativa barata e eficiente para a maioria das aplica-
50
coes paralelas em atividades de pesquisa. Existem pesquisas ate mesmo no sentido de se
usar ciclos ociosos de redes de computadores de uso convencional para processamento de
alto desempenho (ACHARYA et al., 1997). Entretanto, o baixo custo nao implica que ma-
quinas mais potentes, e consequentemente mais caras, possam ser desenvolvidas usando o
mesmo princıpio de memoria distribuıda, como se pode perceber da lista top 500 (STEEN;
DONGARRA, 2004).
Como a memoria e local e portanto invisıvel globalmente em maquinas de memoria distri-
buıda, o compartilhamento de variaveis tem de ser feito explicitamente. Isso leva ao uso
de uma rede de interconexao, que tipicamente e mais lenta que o acesso direto a memoria,
mesmo em redes rapidas como Myrinet. Essa consideracao tem duas implicacoes basicas:
a primeira delas e que problemas que demandem grande quantidade de compartilhamento
de dados e coordenacao entre processadores nao sao apropriados para a arquitetura de
memoria distribuıda com rede de conexao com alta latencia e baixa largura de banda. E
a segunda consideracao e que normalmente a programacao para essas maquinas paralelas
e feita por meio de bibliotecas de comunicacao por troca de mensagens, que demandam
a programacao explıcita dos dados a serem comunicados ou dos pontos de sincronizacao
entre processadores.
O tipo de aplicacao apropriada para o tipo de arquitetura em questao e portanto aquele
que a computacao pode ser divida entre os processadores e cada uma das partes dependa
pouco ou nada das demais. Dessa forma a comunicacao e seu overhead sao mantidos pro-
porcionalmente baixos em relacao ao processamento. Simulacoes de Dinamica Molecular
com potenciais de curto alcance se encaixam nessa condicao, pois a dependencia para o
algoritmo de decomposicao espacial, apresentado no Topico 4.2, fica restrito as bordas
dos domınio, como pode ser visto da Figura 4.3.
Nesse trabalho, a execucao do programa paralelo foi realizada em um cluster de cinco nos
bi-processados IA-32 Pentium III de 1.26 GHz rodando Linux conectados atraves de um
switch Gigabit Ethernet. Apesar da arquitetura possuir um rede de interconexao lenta, os
dispositivo de comunicacao atuais sao capazes de realizar comunicacao autonoma, i.e., sem
intervencao do processador. Isso juntamente com comunicacao nao bloqueada possibilita
que os dados dependentes, como interacoes entre partıculas das bordas, sejam comunicados
independentemente da CPU, o que a libera para realizar outros processamentos, como o
calculo das interacoes das partıculas longe das bordas.
51
Figura 4.3 - Decomposicao em faixas.
4.4 Ferramentas Empregadas
Como mencionado no Topico anterior, em arquiteturas baseadas em memoria distribuıda
a troca de informacoes entre processadores e feita explicitamente atraves de troca de men-
sagens, embora exista a possibilidade de uso de memoria compartilhada virtual ou DSM
(Distributed Shared Memory). Das diversas possibilidades existentes para troca de men-
sagens, MPI foi escolhida para uso nesse trabalho por se tratar de um padrao amplamente
aceito e que esta disponıvel para uma ampla gama de plataformas, variando de cluster de
estacoes de trabalho ate supercomputadores.
A programacao paralela e feita atraves da insercao no codigo a ser paralelizado das cha-
madas a biblioteca MPI. Como foi dito, o programador deve explicitar os dados a serem
comunicados e as necessidades de sincronismo para manter a logica do algoritmo. Assim, a
paralelizacao e uma tarefa nao obvia (RAPAPORT, 1995), o que explica porque nao existe
compiladores paralelizantes para o MPI. O programador deve utilizar alguma ferramenta
para determinar os perfis de tempo de execucao do codigo sequencial para identificar os
trechos crıticos em termos de tempo de processamento, os quais sao candidatos a para-
lelizacao. A insercao das diretivas MPI no codigo exige um conhecimento do algoritmo
e das estruturas de dados associadas a este. Eventualmente, pode-se optar por um novo
algoritmo para o problema em questao, que seja mais adequado a paralelizacao. Em si-
mulacoes de Dinamica Molecular as funcoes do MPI sao usadas principalmente durante o
calculo das forcas (interacoes entre as bordas e troca de migrantes), e praticamente nao
sendo usadas na atualizacao das posicoes e velocidades, uma vez que essa tarefa e local.
52
As funcoes de comunicacao nao-bloqueada descritas no Capıtulo 3, sao usadas para ocultar
o tempo de comunicacao da rede como e apresentado no Topico 4.6, obtendo-se assim
resultados melhores daqueles apresentados em (RODRIGUES et al., 2004). A implementacao
MPICH do padrao MPI-1 foi usada para paralelizar o codigo do motor de simulacao, que
foi compilado com o compilador C da Intel R©.
4.5 Decomposicao do Domınio
Em razao da estrategia de divisao por celulas adotada no motor de simulacao sequencial do
ADKS, a abordagem de decomposicao espacial do domınio, que e a mais intuitiva para esse
metodo, foi adotada para a paralelizacao, sendo que conjuntos de celulas inteiras foram
distribuıdas a cada processador. O domınio 2D foi dividido em faixas de uma dimensao,
como foi visto na Figura 4.2. Tal estrategia minimiza o tempo gasto em latencia, pois cada
processador tem que levar em conta apenas a interacao entre suas partıculas e as partıculas
de dois processadores vizinhos. Um processador generico Pi ira se comunicar com os
processadores Pi−1 a sua esquerda e o processador Pi+1, a direita. Uma divisao retangular
do domınio 2D iria implicar em comunicacao para 8 processadores, os processadores com
o retangulo acima, abaixo, os dois lados e os quatro processadores das diagonais. Em uma
forma similar, um domınio em tres dimensoes pode ser dividido em fatias 3D. Embora
essa abordagem economize no custo de inıcio de comunicacao em relacao a decomposicao
por retangulos numa razao de 2/8, o tempo de transferencia cresce mais rapidamente com
o aumento do numero de partıculas em relacao a decomposicao retangular.
Uma questao chave para a decomposicao do domınio e como tratar as interacoes entre
partıculas nas bordas de cada faixa unidimensional. Como a largura das celulas e normal-
mente a distancia de corte, as bordas sao compostas de duas colunas de celulas, cada uma
em um processador diferente. Dessa forma, para se calcular as forcas de interacao entre
partıculas na sua parte da borda, um processador deve ter as posicoes das partıculas da
parte da borda do processador vizinho. Uma possibilidade para tratar essa questao e cada
processador comunicar sua parte da borda (da direita e da esquerda) para o vizinho cor-
respondente. Dessa forma todos os processadores terao as posicoes de todas as partıculas
com as quais as suas proprias partıculas interagem. Entretanto, essa abordagem nao tira
vantagem da terceira lei de Newton e as forcas de interacao nas bordas sao calculadas
duas vezes. Uma solucao melhor e ter um unico processador para o calculo das forcas para
cada borda. Para cada borda, o processador da direita envia as posicoes de suas partıcu-
las nessa borda para o processador do lado esquerdo, que calcula as forcas de interacao
e entao envia apenas os resultados de volta. Dado um processador Pi qualquer com um
vizinho a esquerda Pi−1 e um vizinho a direita Pi+1, ele envia sua borda esquerda para
Pi−1 e concorrentemente recebe a borda esquerda do processador Pi+1. Entao, ele calcula
53
as interacoes para sua borda direita e envia os resultados para Pi+1 enquanto recebe as
forcas de interacao da sua borda esquerda vindas de Pi−1.
Nas simulacoes realizadas, o caso com 521.187 partıculas (102.400 celulas) e 4 processado-
res, por exemplo, a decomposicao do domınio com a estrategia adotada fornece uma faixa
de 80 celulas de largura para cada processador, sendo que apenas duas ”colunas”de celulas
estao nas bordas, uma a esquerda e outra a direita. Ja no caso de uma simulacao com
1.022.323 partıculas (200.704 celulas), a faixa tem 112 celulas de largura, mas ainda ha
apenas 2 ”colunas” nas bordas. Percebe-se desses exemplos como a quantidade de celulas
das bordas diminui em relacao a quantidade total de celulas.
Um dos efeitos colaterais de se usar divisao espacial do domınio e a possibilidade de des-
balanceamento de carga, isso e, uma situacao em que nem todos os processadores sao
mantidos sempre ocupados fazendo trabalho util. Como o que e distribuıdo no tipo de
decomposicao usado e o espaco, um acumulo de atomos em regioes especıficas leva a
desbalanceamento de carga. Varios trabalhos foram propostos a fim de lidar com essa
questao como (KALE et al., 1998) e (DENG et al., 2000). O presente trabalho nao contem-
pla balanceamento de carga, e sendo assim e suposto uma carga balanceada durante as
simulacoes.
4.6 Algoritmo Desenvolvido
Apresenta-se a seguir o algoritmo desenvolvido para a paralelizacao do motor de simulacao
do ADKS. A implementacao paralela do motor de simulacao pode ser vista, considerando-
se a particao do domınio do problema entre processadores, como sendo um conjunto de
instancias do motor de simulacao sequencial sendo executadas nos processadores, cada
um com seu conjunto local de dados, no caso, posicoes e velocidades das partıculas locais
a cada processador. Mas, diferente da versao sequencial, eles levam em consideracao a
interacao das bordas, descritas no Topico anterior, e o possıvel movimento das partıculas
de uma fatia para outra adjacente (migracao de partıculas). Detalhes sobre esse algoritmo
sao apresentado nesse Topico, enfatizando um dos objetivos que foi perseguido na sua
construcao: a ocultacao do tempo de comunicacao atraves de comunicacao nao-bloqueada.
Em linhas gerais a ideia e realizar o envio e recebimento de dados, como de forcas ou
bordas, ao mesmo tempo que se processa dados locais.
No processo de inicializacao da simulacao, e atribuıdo a cada processador as partıculas
que lhes cabem da divisao do domınio e as velocidades iniciais das partıculas sao ajusta-
das. Essas partıculas sao entao inseridas na grade local de celulas, que basicamente e a
mesma grade encontrada na versao sequencial, entretanto uma coluna extra a esquerda e
54
Figura 4.4 - Grade de celulas local ao processador 2.
necessaria para acomodar as partıculas da borda vindas do processador vizinho (Figura
4.6) conforme descrito no Topico anterior.
Diversas simulacoes de Dinamica Molecular apresentam partıculas que possuem proprie-
dades especiais, como estarem fixas no espaco ou terem um potencial diferente das demais,
e por isso devem ser rotuladas para que durante a simulacao elas sejam tratadas de forma
coerente. Uma alternativa para essa rotulacao e armazenar os ındices de inıcio e fim do
conjunto de partıculas que apresenta uma propriedade em comum, a atribuicao desses
ındices tambem e feita no processo de inicializacao.
Uma vez iniciada a simulacao, cada timestep e executado e tem a forma do seguinte
pseudo-codigo, que e executado em cada processador:
para cada partıcula local
calcula as forcas resultantes sobre as partıculas locais
atualiza as posic~oes e velocidades das partıculas locais
envia particulas emigrantes e recebe imigrantes
fim para
Embora nao haja nenhuma barreira explıcita no codigo de cada timestep, a sua execu-
cao em cada processador e sincronizada pelas comunicacoes, como as das bordas e das
55
Figura 4.5 - Primeiro passo do calculo das forcas.
partıculas migrantes.
O calculo das forcas e o primeiro passo a ser tomando em um timestep, e, como des-
crito no Topico anterior, foi evitado calculos redundantes, para isso a interacao entre as
partıculas das bordas sao processadas por apenas um processador e o resultado e comu-
nicado ao vizinho da borda em questao. E precisamente na comunicacao da borda e no
retorno do resultado calculado que foi usada comunicacao nao-bloqueada para melhorar
a performance da simulacao.
Considerando novamente um processador generico Pi e seus vizinhos a esquerda Pi−1 e
a direita Pi+1, o primeiro sub-passo do calculo das forcas e Pi enviar as partıculas que
compoem a coluna de celulas mais a esquerda, como pode ser visto na Figura 4.6 em relacao
ao processador P2, para o processador Pi−1. Ao mesmo tempo Pi inicia o recebimento da
borda vinda do processador Pi+1, mas nao bloqueia a espera do resultado. Vale lembrar
que como esse algoritmo e baseado em divisao por celulas, as partıculas das bordas nao
estao contıguas na memoria, significando que antes que de fato a borda seja enviada,
suas partıculas devem ser acumuladas em um buffer de saıda antes do envio, e para o
recebimento elas devem ser desempacotadas do buffer de recebimento para suas posicoes
corretas.
Enquanto a comunicacao da borda e feita de forma nao-bloqueada, o processador fica
livre para calcular as interacoes entre as partıculas do interior da faixa. O formato de
56
Figura 4.6 - Exemplos do padrao de varredura das celulas.
varredura das celulas pode ser visto na Figura 4.6 para tres celulas, em que apenas as
celulas hachuradas sao percorridas para o calculo de forcas resultantes sobre as celulas
destacadas, isso e feito para se beneficiar da terceira lei de Newton, pois a interacao com as
vizinhas nao hachuradas sao calculadas quando forem elas as celulas atuais da varredura
nao importando se isso e feito antes ou depois, pois o calculo da forca resultante independe
da ordem da soma das forcas componentes.
Antes de terminar de percorrer as celulas interiores, a comunicacao iniciada termina e en-
tao o processador Pi calcula as forcas de interacoes na borda direita. Ao final do calculo,
as forcas referentes as partıculas que ele recebeu de Pi+1 sao empacotadas num buffer de
saıda e enviados para Pi+1, e ao mesmo tempo e iniciado o recebimento das forcas resul-
tantes na borda oposta vindas de Pi−1. Enquanto essa ultima comunicacao nao termina,
o processador Pi tem a chance de calcular as interacoes do restante de suas partıculas, ao
final do que ele verifica a chegada das forcas de interacao sobre sua borda esquerda.
O calculo das forcas pode ser tambem descrito atraves do pseudo-codigo abaixo
envia coluna mais a esquerda p/ processador esquerdo
inicia recebimento de partıculas do processador direito
calcula forcas nas colunas N - 2 ate M
termina de receber do processador direito
calcula forcas na colula N - 1
57
envia forcas na coluna N para processador direito
inicia recebimento de forcas do processador esquerdo
calcula forcas nas colunas M - 1 ate 0
termina de receber do processador esquerdo
Com as forcas resultantes sobre todas as suas partıculas, cada processador atualiza as
velocidades e posicoes delas, que e uma tarefa local. Em seguida realiza-se a atualizacao da
grade de celulas e eventualmente partıculas saem da area de simulacao de um processador
e devem entao ser comunicadas para o processador da faixa para a qual as partıculas
migraram. A condicao de contorno deve ser levada em consideracao durante o calculo das
forcas e atualizacao das partıculas.
4.7 Validacao do Algoritmo Desenvolvido
Uma maneira de validar o codigo produzido a partir do algoritmo descrito acima e atraves
da execucao de uma simulacao que, por teoria, deve manter energia constante, ou seja
um ensemble microcanonico. O sistema devera estar isolado do meio externo, portanto ele
tendera a um estado de equilıbrio correspondente a energia total (E), que e a soma da
energia cinetica K e a energia potencial U entre as n partıculas de massa m:
E = K + U =n∑
i=1
miv2i
2+
n−1∑i=1
n∑j=i+1
u(rij) (4.1)
em que rij e a distancia entre as partıculas i e j.
Durante o calculo das forcas, tambem e acumulada a energia potencial. Diferente do algo-
ritmo paralelo apresentado em (RAPAPORT, 1995), nao e necessario qualquer verificacao
se a partıcula pertence ao processador ou se ela faz parte das partıculas vindas da borda
do processador vizinho. Esse tambem e um dos benefıcios de se ter eliminado os calculos
redundantes. O calculo da energia cinetica e feito durante a integracao das equacoes de
movimento. Cada processador envia os valores calculados de energia potencial e cinetica
para um processador mestre, que calcula a energia total. Como observado por (RAPA-
PORT, 1995), erros de programacao podem ser detectados se o programa violar as leis de
conservacao de energia.
Uma vez validado o programa, nao ha necessidade do calculo de energia total, ou pelo
menos nao e necessario o calculo a cada timestep, e desta forma fica reduzida a quantidade
de comunicacao.
58
4.8 Escalabilidade de Simulacoes de Dinamica Molecular
Nesse Topico e apresentado uma forma de analise de escalabilidade aplicada a dinamica
molecular para analise dos resultados de desempenho obtidos e apresentados no Topico
seguinte.
Uma forma de lidar com escalabilidade e atraves da metrica de desempenho paralelo
chamada isoeficiencia. Considerando-se um programa paralelo executado com N proces-
sadores para um dado tamanho de problema, este conceito define como esse tamanho deve
aumentar com o aumento de N de forma a se manter a eficiencia constante (GRAMA et
al., 1993), explorando o conceito de scaled speedup visto no Capıtulo 3 em oposicao a Lei
de Amdahl que trata de um problema de tamanho fixo.
A isoeficiencia se baseia na observacao que o speedup tende a saturar com o aumento de
N , i.e., acima de um certo valor nao ocorrem mais ganhos de tempo de execucao. Por
outro lado, o aumento do tamanho do problema para N constante leva normalmente a
um aumento da eficiencia. Programas que apresentam esse comportamento de execucao
paralela poderiam entao ter um aumento do tamanho do problema com o aumento de N
numa taxa que manteria a eficiencia constante. Assim, a execucao paralela se caracteri-
zaria pelo aumento do tamanho dos problemas tratados, mas nao necessariamente pela
diminuicao do tempo de execucao. A metrica de isoeficiencia se baseia nas definicoes de
eficiencia (E) e speedup (σ) apresentadas nas Equacoes 3.2 e 3.3 do Capıtulo 3. O tempo
de execucao paralelo pode ser escrito como:
N ∗ Tp =Ts + To
Tp =Ts + To
N
(4.2)
em que N e o numero de processadores, Ts e o tempo total de execucao na maquina
sequencial, Tp e o tempo total de execucao na maquina paralela e To e o tempo referente
ao overhead total da paralelizacao, o qual e funcao de N e do tamanho do problema.
Como observa (QUINN, 2003), To depende da comunicacao entre processadores e do pro-
cessamento redundante executado localmente nestes. Desta forma o speedup e a eficiencia
podem ser reescritos como:
59
σ =Ts
Tp
=N ∗ Ts
Ts + To
(4.3)
E =σ
N=
Ts
Ts + To
=1
1 + To/Ts
(4.4)
A hipotese de eficiencia constante implica em manter constante o quociente C = To/Ts:
E =1
1 + To/Ts
To
Ts
=1− E
E
Ts =
(E
1− E
)∗ To
Ts =C ∗ To
(4.5)
Portanto, essa hipotese implica que um aumento no tamanho do problema (e o consequente
aumento de Ts) deve ser balanceado por um aumento de To a fim de manter a eficiencia
constante.
Em simulacoes de Dinamica Molecular (DM) com potenciais de curto alcance, o tempo
sequencial e proporcional ao numero de partıculas n, como visto no Capıtulo 2. Definindo-
se Tc como sendo o tempo de comunicacao de um processador da maquina paralela, se
considerarmos que apenas esse tempo influencia To, pode-se escrever que To = N ∗ Tc. Se
tambem for considerado que o domınio da simulacao foi decomposto conforme a Figura
4.3 e suposta uma densidade de partıculas ρ constante, Tc aumentara proporcionalmente
a√
n para um domınio quadrado, pois a comunicacao e restrita as bordas entre as faixas
e estas aumentam com o lado L, que por sua vez se relaciona com n atraves da expressao
L =√
n/ρ. Sendo assim, definindo-se uma nova constante de proporcionalidade C1, a
funcao de isoeficiencia em DM seria dada por:
Ts(n) = C ∗N ∗ Tc = C1 ∗N ∗√
n (4.6)
60
Como o segundo membro varia com√
n, nao aumenta tao rapidamente quanto Ts(n), que
e proporcional a n como visto anteriormente. Isso significa que um aumento no tamanho
do problema (aumento de n) permite manter a eficiencia constante com um aumento de
N que seja proporcional a√
n. Assim, se n quadruplica.√
n dobra e N tambem deve ser
dobrado.
Se novamente for considerado que o overhead da paralelizacao e devido apenas a comuni-
cacao entao a eficiencia para o algoritmo de decomposicao espacial de (PLIMPTON, 1995)
e dada por:
E =1
1 + To/Ts
=1
1 +N ∗ (n/N)2/3
n
(4.7)
A expressao acima pode ser verificada com os dados apresentados no proprio artigo
(PLIMPTON, 1995). Para isto, uma vez que nao aparecem os tempos sequenciais, e os
valores de eficiencia nao podem ser calculados da maneira usual, recorreu-se ao calculo da
eficiencia por meio da expressao:
EA =Ts
TpA ∗ A
Ts =EA ∗ TpA ∗ A
(4.8)
EB =Ts
TpB ∗B
Ts =EB ∗ TpB ∗B
(4.9)
para duas quantidade de processadores (A e B) diferentes pode-se deduzir o tempo para
o caso B a partir do caso A:
EA ∗ TpA ∗ A =EB ∗ TpB ∗B
TpB =EA ∗ TpA ∗ A
EB ∗B
(4.10)
A Figura 4.8, ilustra a deducao do tempo de cada timestep para varios numeros de partıcu-
61
Figura 4.7 - Tempos de execucao para a maquina paralela nCube inferidos de (PLIMPTON, 1995).
las usando-se 1024 processadores a partir de 512 processadores de um nCube 2 apresentado
em (PLIMPTON, 1995). Esse resultado se ajusta bem aos tempos de fato apresentados no
artigo.
4.9 Resultados de Desempenho Paralelo
Apresentam-se a seguir os resultados do desempenho do motor paralelo de simulacao do
ADKS que foi desenvolvido neste trabalho conforme o algoritmo descrito acima. Esse
motor foi executado no cluster descrito no Topico 4.3 para um ensemble micro-canonico
(energia fixa) assumindo-se o potencial de Lennard-Jones. Simulacoes com ate 1.334.695
partıculas sempre para 100 timesteps foram executadas para comparacao com os tempos
sequenciais. Foram experimentados dois esquemas de execucao: o primeiro usando-se ape-
nas um processador por no (denominado aqui esquema ”inter-no”), e o segundo usando-se
dois processadores por no (esquema ”intra-no”). A Tabela 4.1 apresenta uma comparacao
entre a execucao sequencial e a paralela em 2, 4 e 8 processadores, no esquema ”intra-no”.
Os speedups correspondentes sao apresentados na Tabela 4.2 e na Figura 4.9 onde pode-se
ver que estes speedups ficaram abaixo do linear.
Os mesmos testes foram repetidos usando-se apenas um processador por no, entretanto o
caso com 8 processadores nao pode ser executado pois a maquina usada so possui 5 nos. A
Tabela 4.3 apresenta os tempos, uma comparacao entre o esquema com 1 processador por
no e 2 processadores por no e feita atraves dos respectivos graficos de speedup mostrados
62
Tabela 4.1 - Tempo de processamento em segundos para 1, 2, 4 e 8 processadores e n partıculas (esquemaintra-no).
n 1 2 4 81307 0.2661 0.2747 0.1360 0.08395197 1.0908 0.5603 0.2964 0.2032
20847 4.9024 2.4223 1.2304 0.624483503 20.4554 11.1220 5.4574 2.7578
187627 46.6051 25.9623 13.0250 6.6098333787 83.5222 45.8790 23.4633 11.8901521187 131.4039 71.3313 37.0541 18.5680750851 188.2405 106.0074 53.1324 27.5287
1022323 260.1202 142.1227 73.1021 37.63601334695 344.7677 196.1073 97.9193 50.1260
Tabela 4.2 - Speedup para n partıculas em 1, 2, 4 e 8 processadores (esquema intra-no).
n 2 4 8521187 1.8421 3.5462 7.0768750851 1.7757 3.5428 6.8379
1022323 1.8302 3.5583 6.91141334695 1.7580 3.5209 6.8780
na Figura 4.9.
Observa-se do grafico 4.9(b), correspondente ao esquema ”inter-no”, um speedup muito
proximo do linear, o que nao ocorre em 4.9(a), para o uso do esquema ”intra-no”. A mais
provavel explicacao para esse fato e que a execucao paralela da simulacao em dois proces-
sadores do mesmo no leva a uma competicao dos processadores pelo acesso a memoria.
Adicionalmente, embora a arquitetura de cada no, como a maioria dos microcomputadores
e estacoes de trabalho atuais, utilize um ou mais nıveis de memoria cache para otimizar
o acesso a memoria, a estrutura de dados associada ao algoritmo implementado de DM
nao se beneficia tanto desse fato, pois partıculas que interagem entre si (da mesma celula
ou de celulas vizinhas) podem estar armazenadas em posicoes distantes na memoria prin-
cipal de cada no. Dessa forma, a varredura das celulas da fatia local a um determinado
processador pode levar a muitas falhas de cache (cache miss) e a consequente necessidade
de leitura de dados que estao na memoria principal. Testes realizados com um codigo
simples para avaliacao de desempenho de memoria confirmaram que essa contencao pelo
63
Figura 4.8 - Speedup do codigo de DM em execucao intra-no.
Tabela 4.3 - Tempo de processamento em segundos para 1, 2, 4 processadores inter-nos.
n 1 2 41307 0.2662 0.1463 0.09725197 1.0909 0.5684 0.3011
20847 4.9111 2.4352 1.212583503 20.4724 10.3243 5.2192
187627 46.5839 23.4462 11.8863333787 83.4700 42.0948 21.2402521187 131.5231 66.3279 33.5949750851 188.2794 94.7889 47.9709
1022323 260.2314 131.2216 66.11671334695 344.5988 173.2606 87.2315
acesso a memoria principal penaliza o desempenho paralelo, seja no caso de um codigo
otimizado para uso da memoria cache ou nao. Obviamente, no caso da versao desse codigo
que explora a memoria cache, o tempo de execucao foi menor, mas observa-se a mesma
tendencia em relacao ao desempenho nos esquemas ”inter-no” e ”intra-no”.
Da analise de iso-eficiencia apresentada acima, pode-se inferir que, para a decomposicao
proposta em faixas de celulas, e para a hipotese de densidade de partıculas constante (o
numero de celulas aumenta na mesma proporcao que o numero de partıculas):
64
(a) Intra-nos
(b) Inter-nos
Figura 4.9 - Comparacao entre execucao do codigo de DM intra-nos e inter-nos.
65
• a eficiencia deveria diminuir com o aumento de N , pois a granularidade do
problema diminuiria uma vez que para o mesmo tamanho de problema (N), a
comunicacao aumentaria.
• a eficiencia deveria aumentar com o aumento do tamanho da simulacao (n)
para N constante, pois a granularidade do problema aumenta, uma vez que o
overhead da comunicacao diminui sensivelmente em comparacao ao tempo total
de execucao.
• teoricamente, o aumento do problema (n) e o aumento de N numa proporcao
conveniente levaria a valores de eficiencia constante.
Entretanto, as simulacoes paralelas realizadas neste trabalho nao seguiram essas tenden-
cias exatamente, conforme apresentado acima, o que pode ser explicado pelas seguintes
consideracoes:
• no caso de aumento de N para tamanho do problema fixo, a diminuicao da
granularidade pode ser amenizada com o uso de sobreposicao de comunicacao
e processamento, implementada neste trabalho por meio de comunicacao nao-
bloqueada.
• no caso de aumento do tamanho do problema com N fixo, a eficiencia nao pode
melhorar indefinidamente e ultrapassar o valor unitario, a nao ser que haja oti-
mizacao do acesso a memoria devido a particao do domınio entre processadores,
o que nao e o caso das simulacoes deste trabalho. Chegou-se assim a valores de
eficiencia de 98% na configuracao inter-no.
• na pratica, essa sobreposicao nao e ideal e o overhead da paralelizacao inclui
outros tempos alem do tempo de comunicacao, que nao escalam como este.
66
5 SIMULACOES INTERATIVAS EM DINAMICA MOLECULAR
5.1 A Demanda por Interatividade em Dinamica Molecular
Simulacoes de Dinamica Molecular podem ser executadas em modo batch (processamento
em lote), como uma sequencia de passos, tais como: definicao dos dados de entrada (posi-
coes e velocidades das partıculas, temperatura inicial, condicao de contorno etc), execucao
de um certo numero de timesteps pelo motor de simulacao, saıda dos dados para um dis-
positivo de armazenamento e pos-processamento. O resultado final pode entao ser usado
para redefinir os dados de entrada de uma nova simulacao, reiniciando assim o ciclo. Essa
abordagem tem algumas desvantagens: a primeira delas e que a quantidade de dados
armazenados pode crescer muito rapidamente. Para o estudo das trajetorias das partı-
culas, armazenar apenas as coordenadas de um sistema de partıculas grande para varios
timesteps encheria facilmente os dispositivos de armazenamento atuais. Uma segunda des-
vantagem e que os resultados da simulacao apenas ficam disponıveis ao final da simulacao
inteira.
Rapaport em (RAPAPORT, 1995) ja identifica que o estudo de trajetorias e uma tarefa que
melhor se realiza em uma outra abordagem para simulacoes de Dinamica Molecular, que
e ter capacidades visuais e interativas associadas a simulacao. Dessa forma parametros
da simulacao podem ser mudados durante sua execucao, permitindo um feedback visual
em tempo de execucao. Fenomenos complexos que nao podem ser observados em expe-
rimentos reais ou em analise post-mortem de dados obtidos atraves de simulacoes batch,
podem assim ser estudadas em um ambiente computacional interativo. A necessidade por
processamento paralelo e enfatizada a fim de se ter simulacoes interativas com tempos de
execucao que sao confortaveis para o usuario.
Como discutido no Capıtulo 4, existe uma demanda por processamento paralelo em Simu-
lacoes de Dinamica Molecular com grande numero de partıculas. Entretanto Simulacoes
de Dinamica Molecular interativas em particular e programas interativos em geral apre-
sentam um problema extra em sua paralelizacao: como controlar o programa nos diversos
processadores em resposta a interacao do usuario com a interface. Neste trabalho, propoe-
se uma implementacao paralela para o software ADKS de simulacao de DM interativa
com visualizacao, que foi tomado como estudo de caso e e descrito na secao seguinte.
5.2 Estudo de Caso: o Software ADKS
O software ADKS e um programa interativo com visualizacao associada desenvolvido
para o estudo de fraturas e contornos de grao (grain boundary) em solidos atraves de
Dinamica Molecular, como pode ser visto na Figura 5.2. Ele foi desenvolvido pelo INPE
67
em cooperacao com a Universidade de Tecnologia de Helsinki. As partıculas sao exibidas e
atualizadas para um numero de timesteps definido pelo usuario. Parametros da simulacao
podem ser modificados durante a simulacao a fim de permitir o estudo de suas influencias,
provendo assim um ambiente interativo para a simulacao. Alem disso, esse programa
permite analise em profundidade de complexos fenomenos transitorios, tais como fratura
em materiais.
(a) contorno de grao (b) fratura
Figura 5.1 - Defeitos em solidos.
O ADKS consiste basicamente de tres modulos fortemente relacionados em um programa
monolıtico, sao eles: um motor sequencial de simulacao de DM, uma janela grafica para
saıda de dados e uma interface de usuario para entrada de parametros, esse ultimo especı-
fico para o problema de fraturas e contornos de grao. Esses modulos sao integrados em um
ambiente dirigido a eventos que trata a transferencia de informacoes entre os modulos, e
permite o processamento de qualquer acao requerida pelo usuario durante a simulacao. A
simulacao pode inclusive ser parada por uma acao do usuario e retomada posteriormente.
O programa foi escrito em C e desenvolvido para a plataforma X11 Window System, tipi-
camente encontrada em ambientes Unix. Os componentes visuais (widgets) sao baseados
na biblioteca Motif.
Uma vantagem imediata da estrategia do ADKS e economizar espaco de armazenamento.
Se os dados da simulacao fossem gravados no disco, as coordenadas de todas as partıcula
para todos os timesteps iriam requerer centenas ou mesmo milhares de megabytes para
uma simulacao tıpica de DM. A adicao dos dados de velocidade iriam dobrar essa ne-
cessidade. Ao contrario, a abordagem interativa, atualizando continuamente os dados na
tela combinada com a possibilidade de armazenamento das configuracoes em uma forma
68
seletiva, mantem a requisicao por espaco de armazenamento em um nıvel baixo. Uma
outra caracterıstica do ADKS e a maneira pela qual estados de equilıbrio ou proximo ao
equilıbrio podem ser identificados diretamente de uma inspecao visual. Isso e desejavel em
muitas circunstancias, por exemplo quando estudando os efeitos de novas condicoes de si-
mulacao, tais como variacao na intensidade de forca aplicada ou temperatura. Um estudo
similar em uma abordagem convencional de simulacao iria requerer um grande numero de
iteracoes do ciclo executa-simulacao/analisa-dados/executa-simulacao. Entretanto, a me-
lhor vantagem do ADKS e obtida na analise de sistemas que apresentam efeitos dinamicos,
tais como no caso de fraturas de materiais. As analises de pos-processamento dos dados
seriam muito limitados e uma animacao completa iria representar um grande problema de
armazenamento sem o benefıcio da exibicao em tempo de execucao. Por exemplo, o ADKS
tem a habilidade de seguir o desenvolvimento de fenomenos como a emissao e propagacao
de deslocamentos em um material poli-cristalino.
5.3 Solucoes Existentes para o Problema da Interatividade em Ambiente
Paralelo
Algumas solucoes ja foram propostas para a questao da interatividade em simulacoes
paralelas e que podem ser aplicadas nas simulacoes de dinamica molecular, como por
exemplo o sistema Falcon (GU et al., 1998), que e composto de um conjunto de ferramentas,
bibliotecas e interfaces de usuario para capturar dados de codigos paralelos, analisar e
exibir esses dados e permitir configuracao em tempo de execucao (on-line) do programa.
Essa configuracao pode ser realizada por um usuario interagindo com o sistema, que e
conhecido como program steering, ou por um outro programa, que e conhecido como
adaptacao de programa.
Segundo (GU et al., 1998), a contribuicao do Falcon reside no suporte que ele da a criacao
de programas configuraveis em tempo de execucao para uma ampla gama de fins e plata-
formas. Entretanto e questionavel a ideia de o sistema Falcon poder executar em varias
plataformas, uma vez que sua implementacao depende de threads e memoria comparti-
lhada.
O uso do Falcon se da atraves da instrumentacao do codigo da aplicacao com sensores, que
sao basicamente uma estrutura de dado e uma rotina a ser inserida nos pontos do codigo a
ser monitorado. Durante a execucao, as informacoes sobre o programa sao capturadas pela
rotina do sensor e possivelmente pre-analisadas. As informacoes geradas sao armazenadas
em filas para entao serem analisadas pelos monitores locais, que sao threads que analisam
os dados e encaminham para filtragem e exibicao. E possıvel instruir o Falcon a habilitar
ou desabilitar os sensores de modo a aumentar os detalhes do monitoramento ou diminuir
69
a perturbacao da execucao do codigo do programa.
A capacidade de configuracao on-line provida pelo Falcon e baseada em dois componentes:
o cliente de steering, que atua como interface entre o usuario e a simulacao, e o servidor
de steering, que compartilha memoria com as threads da aplicacao e pode alterar os
parametros da aplicacao diretamente. Esses dois componentes se comunicam para permitir
o ajuste de parametros on-line.
A dependencia do Falcon por threads e a menor escalabilidade de maquinas de memoria
compartilhada tornam o sistema Falcon uma solucao restrita.
Uma outra solucao para o problema da interatividade foi proposta por (BEAZLEY; LOM-
DAHL, 1997). Eles identificaram que a quantidade de partıculas em uma simulacao de
Dinamica Molecular era limitada nao pela capacidade de processamento de que dispu-
nham para executar as simulacoes, mas sim pela quantidade de dados que eram gerados
e que deviam ser mostrados em estacoes de trabalho convencionais. Alem disso eles per-
ceberam a necessidade de controle da simulacao em tempo de execucao, pois nao era
interessante executar uma simulacao por um longo perıodo para somente depois de sua
finalizacao se perceber que algum parametro deveria ter um valor diferente.
Eles propuseram entao uma metodologia que consiste em unir visualizacao, analise e simu-
lacao. Isso foi feito atraves do uso de uma linguagem script, o Python, e uma ferramenta
para construir modulos e extensoes. A linguagem script faz a ligacao entre o codigo de
Dinamica Molecular (eles usaram um codigo ja existente chamado SPaSM - Scaleable Pa-
rallel, Short-Range Molecular Dynamics, uma biblioteca de dinamica molecular de alta
performance) e as ferramentas de analise e de visualizacao (Figura 5.3).
Beazley e Lomdahl modificaram o interpretador do Python para executar em cada proces-
sador de um supercomputador, mas as operacoes de entrada e saıda eram centralizadas em
um unico processador. Desta forma um comando fornecido ao interpretador e lido apenas
por um processador, que o envia para os demais processadores. Com este ambiente criado,
aplicacoes interativas podiam ser desenvolvidas como modulos do Python.
O que mais chama a atencao na proposta de Beazley e Lomdahl e a extensibilidade dela.
Modulos podem ser facilmente acrescentados para prover novas funcionalidades. Um dos
modulos desenvolvidos foi um modulo grafico que gera na maquina paralela imagens do
sistema sendo simulado de forma eficiente, mesmo para sistemas grandes com muitos mi-
lhoes de partıculas, a renderizacao consome menos tempo que a execucao de um timestep.
Essa estrategia tem a vantagem de desenvolvimento rapido de novas simulacoes, mas
70
Figura 5.2 - Visao geral da solucao de Beazley e Lomdahl.
Fonte: Beazley, Lomdahl (1996).
sua execucao e levemente mais lenta que uma abordagem monolıtica, com um sistema
totalmente escrito em C. Alem disso a versao do Python usada e proprietaria, nao estando
disponıvel para uso amplo.
5.4 Questoes sobre Interatividade na Arquitetura Empregada
Em uma simulacao interativa executada em uma maquina sequencial, um simples modelo
de programacao baseado em eventos fornece o ambiente necessario a interacao do usuario,
i.e., a modificacao de parametros da simulacao sem reinicia-la novamente. Uma versao
paralela desse modelo para uma arquitetura de memoria compartilhada iria simplesmente
requerer o desacoplamento da interface de visualizacao do motor de simulacao. Similar-
mente ao modelo sequencial, eventos podem modificar parametros da simulacao que e
executada em multiplas threads, contanto que essas modificacoes sejam feitas antes da
leitura dos parametros por qualquer uma das threads de simulacao no inıcio de um times-
tep. Entretanto, em uma maquina paralela de memoria distribuıda, essa estrategia nao
pode ser usada. Quando um programa que usa a abordagem de passagem de mensagem
e executado em uma maquina de memoria distribuıda, multiplos processos independentes
sao iniciados nos diferentes nos ou processadores da maquina.
Um possıvel esquema para arquiteturas de memoria distribuıda e atribuir a interface de
usuario e a visualizacao correspondente a um processador especıfico dotado de terminal,
e executar o motor de simulacao nos processadores restantes. O processo de visualizacao
tambem coleta os resultados da simulacao dos outros processadores atraves de mensagens
a intervalos especıficos de timesteps para exibicao. A interface de usuario deve permitir
a modificacao de parametros da simulacao, para isso tambem sao enviadas mensagens da
71
(a) Motor da simulacao (b) Interacao interface e motor de si-mulacao
Figura 5.3 - Modelo baseado em automatos finitos.
interface para os outros processadores a fim de informa-los sobre alteracoes na simulacao.
Desta forma o motor de simulacao pode ser modelado como um automato finito, sendo
que as transicoes sao disparadas pelas mensagens vindas da interface para mudar o estado
da simulacao.
Um modelo simplificado e descrito na Figura 5.3(a). O estado inicial C representa a
criacao de uma nova simulacao que pode ser mudado para o estado de execucao E. A
transicao de E para C e usada para interromper a simulacao corrente e iniciar uma nova.
A transicao para o estado S causa o fim da simulacao. A transicao ajusta permite mudar
parametros durante a simulacao, por exemplo, a temperatura ou a pressao, enquanto a
transicao configura trata de parametros estaticos, que podem ser configurados apenas
antes da simulacao comecar, como o numero de partıculas e o tamanho do domınio de
simulacao. Dessa forma, o sistema completo modela a interacao entre uma interface de
usuario executada num no provido de terminal e um conjunto de automatos finitos sendo
executados nos nos de processamento (Figura 5.3(b)).
5.5 O Ambiente PyMPI
A implementacao do modelo apresentado no topico anterior pode tomar a forma de um
programa monolıtico, em que todas as funcoes como visualizacao, interface e motor de
simulacao sao embutidas em uma unica imagem executavel. Esse executavel e entao exe-
cutado em cada no do cluster, mas apenas no no mestre (provido de terminal) instancia
a interface com o usuario enquanto que nos outros nos e executado o motor da simulacao
(Figura 5.5). Um protocolo especıfico tem de ser desenvolvido para comunicacao entre os
modulos afim de implementar a abstracao de automato finito.
Essa abordagem tem algumas desvantagens. A primeira delas e que mesmo que os nos
72
Figura 5.4 - Imagem executavel da abordagem monolıtica.
que executam o motor de simulacao nunca precisem usar qualquer biblioteca grafica, como
Motif, eles serao obrigados a ser ligados a esse tipo de biblioteca, quer estaticamente quer
dinamicamente, se a interface de usuario usa-la. Uma segunda desvantagem e que uma
modificacao em algum aspecto do motor de simulacao ou da interface ira requerer que o
conjunto inteiro seja recompilado.
Uma melhor estrategia para esse tipo de simulacao e separar interface de usuario e vi-
sualizacao do motor de simulacao como modulos independentes que se comuniquem por
uma interface previamente definida. Esses modulos foram construıdos como bibliotecas de
vınculo dinamico para sem carregados no ambiente PyMPI que estende a linguagem de
programacao Python para um ambiente paralelo usando MPI.
Python e uma linguagem de programacao interpretada e orientada a objetos, que ganhou
popularidade por causa da sintaxe clara e legibilidade. Ela e dita ser relativamente facil
de se aprender e portavel para um grande numero de plataformas. Seu codigo fonte esta
disponıvel livremente e aberto para modificacoes e reuso. Python oferece tipos de dados
dinamicos, bibliotecas de classes prontas e interfaces para muitas bibliotecas e chamadas
de sistema.
Duas importantes caracterısticas do Python sao (1) uma interface de usuario dirigido a
comandos semelhante ao Matlab R© e Mathematica R©, que permite execucao interativa
de comandos, e (2) a extensibilidade dinamica da linguagem com codigos escritos em C
e C++, como funcoes e objetos, que pode ser incorporado como comandos do Python.
Essas caracterısticas sao uteis para desenvolvimento de prototipos pois ele fornece um
73
ambiente interativo simples e uma forma de dinamicamente integrar modulos, desde que
esses modulos tenham uma interface bem definida.
Figura 5.5 - Ambiente PyMPI.
PyMPI estende o Python para ser executado em arquitetura de memoria distribuıda
usando a biblioteca MPI. No ambiente PyMPI cada no do computador executa uma
imagem do Python, mas a interface de usuario executa no no mestre, que possui um
terminal (Figura 5.5). Qualquer comando fornecido nesse no e enviado para todos os nos
por meio de chamadas MPI. O PyMPI tambem inicia o ambiente MPI, e uma abordagem
SPMD e usada para atribuir as tarefas aos processadores de acordo a seus ranks. Modulos
que sao carregados no PyMPI podem chamar as rotinas MPI pois o ambiente MPI e
iniciado.
5.6 Desenvolvimento de Extensoes para Python e PyMPI
A inclusao de novos comandos no ambiente Python e PyMPI pode ser feita diretamente
como descrito em (ROSSUM; JR., 2004), uma vez que o Python define um conjunto de fun-
coes, macros e variaveis que fornece acesso a maioria dos aspectos do sistema de execucao
da linguagem. Entretanto essa abordagem e tediosa e sucetıvel a erros, uma melhor alter-
nativa e a geracao automatica de interfaces para o ambiente Python atraves da ferramenta
Swig.
Um exemplo de integracao de um codigo sequencial de Dinamica Molecular usando-se
Swig para geracao da interface e mostrado a seguir. No codigo sequencial existe uma
74
rotina de execucao de n timesteps, como descrito abaixo:
// adksSeq.c
void MDCycle(int n) {
...
}
Deve ser criado um arquivo (adksSeq.i) que descreve a interface para a rotina acima, como
se segue:
%module adksSeq
extern void MDCycle(int);
O Swig entao gera as interfaces necessarias para integracao desse novo comando no ambi-
ente Python, que e compilado juntamente com o codigo da funcao MDCycle como uma
biblioteca de vınculo dinamico (shared library):
shell> swig -python adksSeq.i
shell> cc -c adksSeq.c adksSeq_wrap.c -I/usr/local/include/Py
shell> ld -shared adksSeq.o adksSeq_wrap.o -o adksSeq.so
O modulo pode entao ser carregado e executado no ambiente Python:
shell> python
>>> from adksSeq import *
>>> MDCycle(100);
nesse exemplo sao executados 100 timesteps.
75
5.7 Integracao Desenvolvida da Visualizacao com o Motor de Simulacao
Para integrar modulos ao Python e PyMPI e fundamental determinar que objetos e fun-
coes desses modulos (no caso, escritos em C ou C++) deverao ser disponibilizados para o
ambiente Python na forma de comandos. A fim de integrar o motor de simulacao apresen-
tado no capıtulo anterior e o ambiente PyMPI, interfaces foram criadas para as principais
rotinas do motor de simulacao atraves do Swig descrito no topico anterior. Como exemplo,
funcoes para rodar um timestep, configurar as posicoes e velocidades iniciais das partıculas
e ajustar as condicoes iniciais do sistema foram integradas ao Python. Alem dessas, fun-
coes especıficas e suas respectivas interfaces foram criadas para escrever e ler parametros
da simulacao. O conjunto das principais funcoes exportadas do motor de simulacao para
o ambiente Python e suas descricoes podem ser vistos na Tabela 5.1.
Tabela 5.1 - Funcoes do software ADKS.
funcao descricaoinit sim() inicia uma nova simulacaoSetDefaults() ajusta parametros de simulacao para valores padraoCalcAtoms() posiciona partıculasInitRun() inicia uma execucaoMdCycle() executa um timestepsetLowTemp(int) ajusta controle de temperatura (booleano)setFixed(int) ajusta bordas fixas (booleano)setCrack(int) ajusta fratura inicial (booleano)setCrackCenter(double, double) ajusta posicao da fratura inicialsetCrackSize(double, double) ajusta tamanho da fratura inicialsetBoundary(int) ajusta contorno de graosetStrain(double, double) ajusta forca aplicada e o tempo em que ela e aplicadasetRotation(double, double) ajusta rotacao entre as interfaces em
problemas de contorno de graosetDisplace(double, double) ajusta deslocamento entre as interfaces em
problemas de contorno de graosetEpsilon(double) ajusta valor de ε no potencial de Lennard-JonessetRCut(double) ajusta raio de cortesetLParam(double) ajusta a distancia entre partıculas (Lattice)setSize(double, double) ajusta o tamanho da area de simulacao
Uma descricao completa de cada funcao apresentada na Tabela 5.1, bem como as unidades
usadas nas simulacoes, podem ser encontradas no artigo sobre o ADKS (MERIMAA et al.,
2000).
76
Como o ambiente MPI e iniciado pelo PyMPI, e possıvel carregar o modulo do motor de
simulacao em um subconjunto dos nos do cluster e executar um certo numero de timesteps,
por exemplo.
Figura 5.6 - Integracao da interface de usuario e o motor de simulacao.
As interfaces criadas compuseram um conjunto de rotinas de baixo nıvel usadas para
implementar um objeto Python que representa uma simulacao. Uma instancia desse objeto
pode entao ser criada nos nos destinados ao motor de simulacao (back-end), deixando o
no mestre (front-end), que possui terminal, livre. Assim, quando um metodo particular
do objeto de simulacao e chamado pelo usuario, as correspondentes rotinas de baixo nıvel
sao executadas nos nos correspondentes, isto e, aquelas a cargo do motor de simulacao.
A vantagem dessa abordagem e a implementacao simples do automato finito descrito no
topico 5.4, na qual os estados do objeto de simulacao representam os estados do automato
e as mensagens para fazer as transicoes de estado sao providas pelo ambiente PyMPI.
Entretanto, usa-se uma interface de usuario dirigida a comandos e nao a eventos como no
ADKS original.
A selecao de qual processador vai executar qual modulo e definida no inıcio da computa-
cao: cada modulo determina quantos processadores sao necessarios, sendo atribuıdo um
comunicador MPI a cada modulo. No trabalho atual, apenas o motor de simulacao e
executado em paralelo, sendo a visualizacao executada sequencialmente.
A visualizacao foi escrita baseada na biblioteca Motif, mas outras bibliotecas podem ser
empregadas e integradas sem afetar o motor de simulacao. Considerando N processadores,
77
o modulo de visualizacao e executado pelo processador mestre, e os demais N − 1 pro-
cessadores sao usados pelo motor de simulacao. O modulo de visualizacao e composto de
duas partes: um interface para o motor de simulacao e o visualizador propriamente dito,
que nessa implementacao abre uma unica janela para exibicao das partıculas. Dentro do
ambiente PyMPI, uma rotina de controle denominada nstep, no caso escrita na linguagem
C, determina que o motor de simulacao execute um numero de timesteps usando um certo
numero de processadores estipulado pelo usuario. Essa rotina interfaceia com o motor de
simulacao de forma a coletar e enviar, por meio de chamadas MPI, as posicoes atualiza-
das das partıculas para o no mestre, o qual as utiliza para a visualizacao. Outros dados,
alem das posicoes, podem ser coletados, por exemplo, a temperatura a cada timestep.
Atraves do ambiente PyMPI o usuario pode submeter comandos para ajustar a simulacao
executada nos nos de back-end (Figura 5.7). Essa rotina permite entao que o motor de
simulacao seja totalmente desacoplado da visualizacao.
Figura 5.7 - Interface e Visualizacao no ambiente PyMPI.
Uma vez que o controle da interface PyMPI (linha de comando) retorna apenas depois
que um comando do usuario e completamente executado, nao e possıvel executar um
novo comando. Particularmente, um usuario pode abrir a janela de visualizacao, mas nao
podera disparar um outro comando enquanto essa janela estiver aberta. Uma possıvel
abordagem, a qual foi adotada para resolver esse problema, e o uso de threads a cargo
da visualizacao e da interface de usuario no no mestre, sendo esta ultima thread tambem
responsavel pelo recebimento de dados vindos do motor da simulacao.
Uma melhor alternativa seria ter, em cada no que executa o motor de simulacao paralelo,
78
duas threads, uma para receber comandos do usuario, algo semelhante ao servidor de
steering do Falcon, e outra para, interagindo com os demais processadores, executar o
motor de simulacao. Entretanto, isso nao e possıvel pois as implementacoes disponıveis do
padrao MPI nao sao thread-safe, e sendo assim nao se pode ter duas threads que acessem
o ambiente MPI em um mesmo processador.
5.8 Resultados de Desempenho Paralelo
Primeiramente, todas as simulacoes com esquema ”inter-no”descritas no Capıtulo 4 foram
repetidas incorporando visualizacao na mesma maquina paralela. A rotina nstep permite
definir o intervalo de timesteps para atualizacao das posicoes das partıculas na visuali-
zacao. No caso, optou-se por um intervalo de 10 timesteps. Foram empregados 1, 2 e 4
processadores para executar o motor de simulacao e um outro processador (mestre) para
exibicao. Os resultados sao apresentados na Tabela 5.2.
Tabela 5.2 - Tempo de execucao de 100 timesteps.
n 1 2 41307 0.2796 0.1545 0.10445197 1.1418 0.5957 0.3141
20847 5.1165 2.6011 1.259083503 21.3947 10.9044 5.6035
187627 48.7810 24.7679 12.7156333787 87.0994 44.2358 22.7180521187 136.7093 69.7254 35.8240750851 197.2792 100.1944 51.2215
1022323 272.2060 138.0374 70.49771334695 360.3080 182.6609 93.2398
Percebe-se da tabela acima um pequeno aumento no tempo de execucao em relacao aos
resultados apresentados na Tabela 4.1, devido ao envio das coordenadas das partıculas
dos nos do motor de simulacao para o no mestre. Observa-se porem que a razao de
aumento do tempo de execucao em relacao aqueles resultados diminui com o aumento
de N . Isso pode ser explicado pela diminuicao da comunicacao associada ao envio das
coordenadas das partıculas, pois o tamanho das mensagens diminui uma vez que o numero
de partıculas (ou celulas) em cada processador fica menor. O grafico correspondente de
speedup e apresentado na Figura 5.8.
Alem do caso descrito acima, foram tambem executados com visualizacao e ate 8 proces-
79
Figura 5.8 - Speedup do motor de simulacao acoplado a visualizacao.
sadores, os quatro exemplos apresentados em (MERIMAA et al., 2000). Os dois primeiros
exemplos sao simulacoes de contorno de grao, o primeiro deles sendo simetrico, como
pode ser visto na Figura 5.9(a), e o segundo assimetrico, Figura 5.9(b). Os parametros da
simulacao foram ajustados conforme a Tabela 5.3.
(a) Simetrico (b) Assimetrico
Figura 5.9 - Contorno de grao.
Os tempos de execucao dessas simulacoes sao mostradas nas Tabelas 5.4 e 5.5. Para o
80
Tabela 5.3 - Parametros para os exemplos de contorno de grao.
Contorno de GraoSimetrico Assimetrico
Lattice 1.0 1.0Potencial e: 1 1
rc: 2.1 2.1Rotacao l: 6 9
r: -6 0Afastamento x: 0.5 0.6
y: 0.6 -0.3
caso simetrico, alem da simulacao com area 80× 40 (correspondendo a 7.345 partıculas),
encontrada no artigo (MERIMAA et al., 2000), foram executadas simulacoes com area 160×80 (29.467 partıculas) e area 240×120 (66.380 partıculas). O caso assimetrico foi executado
com area de simulacao 80×45 (8.307 partıculas), 160×90 (33.062 partıculas) e 240×135
(74.610 partıculas).
Tabela 5.4 - Tempo de execucao de 5.300 timesteps para simulacao de contorno de grao simetrico.
n 1 2 4 87345 88.568998 47.106046 24.334076 12.968859
29467 401.911144 205.083078 103.889321 54.21056066380 929.354369 490.740248 255.150678 130.241497
Tabela 5.5 - Tempo de execucao de 7.000 timesteps para simulacao de contorno de grao assimetrico.
n 1 2 4 88307 133.586811 68.195176 36.448523 19.354405
33062 602.136092 310.250278 157.441300 80.71819374610 1379.600467 739.139358 381.372079 195.252317
O terceiro e quarto exemplos encontrados no artigo (MERIMAA et al., 2000) ilustram os
casos limite de fraturas ruptil (Figura 5.10(a)) e ductil (Figura 5.10(b)). Os parametros
para essas simulacoes sao apresentados na Tabela 5.6.
81
(a) fratura ruptil (b) fratura ductil
Figura 5.10 - Fraturas ruptil e ductil.
Tabela 5.6 - Parametros para os exemplos de fraturas.
FraturasDuctil Ruptil
Lattice 1.0 1.0Potencial e: 1 20
rc: 2.1 2.1
Os parametros de tamanho da area de simulacao, posicao e tamanho das fraturas iniciais
sao mostrados na Tabela 5.7. Os tempos de execucao para 1, 2, 4 e 8 processadores sao
apresentados nas Tabelas 5.8 e 5.9.
O numero de partıculas adotada para execucao das simulacoes foi suficiente para caracte-
rizar os fenomenos que se desejava observar nos exemplos de contorno de grao e fraturas.
Plimpton em (PLIMPTON, 1995) ressalta que, na maioria das simulacoes de DM, o numero
de partıculas e escolhido o menor possıvel desde que se consiga reproduzir adequadamente
os efeitos fısicos sob estudo. A paralelizacao implementada mostrou-se conveniente para
as simulacoes efetuadas.
Vale ainda ressaltar a questao da geracao sequencial das imagens do sistema de partıculas.
Essa abordagem, embora ainda apropriada para os casos executados, tende a ser ineficiente
para casos com numeros ainda maiores de partıculas, nos quais o tempo de geracao de cada
frame pode mesmo superar o numero de timesteps otimo de atualizacao das coordenadas,
82
Tabela 5.7 - Parametros de tamanho dos exemplos de fraturas.
Ductiltamanho centro da fratura tamanho da fratura60× 20 (0.0 , 7.5) (1.0, 5.0)
120× 40 (0.0 , 20.0) (2.0, 10.0)180× 60 (0.0 , 30.0) (3.0, 15.0)240× 80 (0.0 , 40.0) (4.0, 20.0)
Ruptil60× 30 (0.0 , 12.5) (1.0, 10.0)
120× 60 (0.0 , 20.0) (2.0, 20.0)180× 90 (0.0 , 30.0) (3.0, 30.0)
240× 120 (0.0 , 40.0) (4.0, 40.0)
Tabela 5.8 - Tempo de execucao de 1.567 timesteps para simulacao de fratura ductil.
n 1 2 4 82777 9.562373 5.435528 3.186609 1.975298
10977 40.505105 21.031154 11.347255 6.66402024579 97.821585 51.372628 26.031215 12.83147744293 179.465757 96.389453 49.293028 23.510301
Tabela 5.9 - Tempo de execucao de 1.500 timesteps para simulacao de fratura ruptil.
n 1 2 4 84123 13.828924 7.471437 4.152235 2.561008
16361 61.476172 31.399110 16.268266 9.26789437191 149.613864 79.329838 41.498235 20.23281965845 265.627077 144.961137 76.991913 41.969928
levando a uma visualizacao descontınua no espaco (se a atualizacao ocorrer a uma taxa
menor a desse valor otimo) ou no tempo (se ocorrer atraso na composicao do frame). Nesses
casos, uma solucao seria gerar os frames em paralelo, nos proprios nos que executam o
motor de simulacao ou em outro subconjunto de nos da maquina paralela.
83
6 CONCLUSAO
6.1 O Motor Paralelo de Dinamica Molecular Desenvolvido
Simulacoes em Dinamica Molecular, que envolvem a solucao do problema classico de N-
corpos (N-body) no contexto do estudo da materia em nıvel atomico, tem se mostrado
uma importante ferramenta de pesquisa em muitas areas da ciencia. Entretanto, as limi-
tacoes impostas a quantidade de partıculas que podem ser simuladas em computadores
sequenciais e a relativa facilidade de se decompor o problema da simulacao em unida-
des quase independentes tornam a computacao paralela uma alternativa atraente para
simulacoes com maior numero de partıculas em tempos de execucao viaveis. O software
ADKS, escolhido para estudo de caso nesse trabalho e um software interativo de simu-
lacao de Dinamica Molecular para o estudo de defeitos em solidos, como por exemplo
fraturas (MERIMAA et al., 2000). Inicialmente, paralelizou-se apenas o motor de simulacao
do ADKS.
No Capıtulo 4 foram apresentadas tres estrategias tıpicas para a paralelizacao algoritmos
de Dinamica Molecular: decomposicao por atomos, decomposicao por forcas e decomposi-
cao espacial, que se diferenciam pela forma como particionam o domınio para execucao em
computadores paralelos. Nesse trabalho foi usado o algoritmo de decomposicao espacial
aplicado ao motor de simulacao do software ADKS. A decomposicao do domınio bidimen-
sional foi feita em faixas unidimensionais: essa abordagem tem a vantagem de diminuir
o numero de processadores com que um dado processador se comunica. Essa vantagem e
util no tipo na arquitetura usada, uma maquina de memoria distribuıda composta de nos
biprocessados com rede de alta latencia.
Uma estrategia usada na paralelizacao do motor de simulacao do ADKS foi o uso de comu-
nicacao nao-bloqueada, a qual possibilita sobreposicao de processamento e comunicacao.
Como a decomposicao do domınio e espacial e o potencial de interacao entre partıculas e
de curto alcance, as partıculas que estao nas bordas do domınio local de cada processador
interagem com partıculas em outros processadores. Por outro lado as partıculas fora das
bordas do domınio local sao completamente independentes da influencia das partıculas em
outros processadores. Na implementacao realizada, a comunicacao decorrente das partıcu-
las nas bordas ocorre enquanto se processam dados do domınio local (exceto as bordas).
Finda a comunicacao, sao entao processadas as partıculas das bordas.
Testes realizados na arquitetura utilizada com a versao paralela implementada do motor de
simulacao mostraram contencao no acesso a memoria pelos processadores em um mesmo
no. Esses resultados foram confirmados com testes de acesso a memoria, que mostram
85
aumento no tempo de execucao quando mais de um processo faz muitas referencias a me-
moria principal. Novas execucoes desse motor paralelo de simulacao foram feitas usando-se
apenas um processador por no, o que resultou em um speedup proximo do linear.
Considerando-se a teoria de isoeficiencia e a decomposicao do domınio adotada, deveria-se
observar, nos resultados de desempenho da implementacao realizada, um aumento na efici-
encia com o aumento do tamanho da simulacao e mantendo-se o numero de processadores
constante, pois a comunicacao tende a diminuir em relacao a computacao. Entretanto isso
nao foi observado, pois a eficiencia ja e muito proxima da ideal para simulacoes executadas
em um processador por no. Isso se justifica pela comunicacao nao bloqueada que leva o
tempo gasto em comunicacao para um valor proximo de zero, e sendo assim aumentos no
tamanho da simulacao nao teriam tanta influencia na diminuicao da comunicacao, que ja
e muito baixa, obtem-se assim eficiencias proximas da ideal para diversos tamanhos de
simulacao.
6.2 Implementacao Desenvolvida para Simulacoes Interativas e Paralelas de
Dinamica Molecular
Simulacoes de Dinamica Molecular podem ser implementadas como programas que sao
executados em modo batch. Um ciclo formado pelos passos de entrada de dados, execu-
cao, analise de dados, e realimentacao do usuario representa esse tipo de simulacao. Uma
alternativa a essa abordagem e fornecer ao usuario capacidade de interacao, normalmente
acompanhada de visualizacao. Tal alternativa permite modificacao de parametros de si-
mulacao e visualizacao dos efeitos produzidos durante a propria simulacao. Fenomenos
complexos que nao podem ser observados em experimentos reais ou que dificilmente se-
riam obtidos em analise pos-mortem, podem ser entao estudados nesse tipo de ambiente
computacional. Entretanto a paralelizacao de simulacoes interativas e visuais nao e trivial.
Algumas alternativas foram propostas para fornecer interatividade em simulacoes pa-
ralelas. O sistema Falcon descrito em (GU et al., 1998) e composto por um conjunto de
ferramentas, bibliotecas e interface de usuario para executar simulacoes, visualizar dados e
prover interatividade. Uma outra alternativa apresentada em (BEAZLEY; LOMDAHL, 1997)
emprega uma versao da linguagem de programacao Python para coordenar simulacao e
visualizacao de um codigo de Dinamica Molecular chamado SPaSM (Scaleable, Parallel,
Short-range Molecular Dynamics), no qual o interpretador Python foi modificado para
ser executado em todos os processadores de um computador paralelo, mas as entradas de
comandos sao centralizados em um terminal apenas.
Neste trabalho foi apresentada uma nova alternativa para execucao de simulacoes paralelas
86
e interativas de Dinamica Molecular. A abordagem utilizada e semelhante a apresentada
em (BEAZLEY; LOMDAHL, 1997), entretanto foi utilizado o PyMPI, que estende o Python
para ambiente MPI e que tem seu codigo fonte aberto. O motor de simulacao desenvolvido
foi integrado ao ambiente PyMPI de forma a tornar disponıvel as rotinas do software
ADKS na forma de comandos do PyMPI. Sendo assim o usuario pode carregar o motor de
simulacao em um subconjunto dos nos da maquina paralela e executar uma simulacao. Um
modulo de visualizacao foi criado para receber os dados enviados do motor de simulacao
para visualizacao. Esse modulo e executado como uma thread diferente da que executa
o terminal do PyMPI no no mestre. Isso e necessario para permitir que o controle do
terminal retorne ao se abrir a janela de exibicao, possibilitando que novos comandos
sejam fornecidos pelo usuario. A simulacao pode ser interrompida e novos parametros
submetidos atraves de comandos PyMPI.
Alem dos casos de teste de desempenho do Capıtulo 4 novos testes foram feitos com as
simulacoes executadas com visualizacao. Esses novos casos correspondem aos exemplos
apresentados no artigo (MERIMAA et al., 2000) sobre o ADKS. Os resultados de desempe-
nho das simulacoes executadas com visualizacao mostraram uma aumento do tempo de
execucao condizente com a carga extra devido ao envio das coordenadas das partıculas
para o no mestre, a cargo da visualizacao das partıculas.
6.3 Consideracoes Finais
Quanto ao motor paralelo de simulacao do software ADKS, parece nao haver espaco para
melhorias de desempenho, pois a eficiencia ja e muito proxima da ideal. Embora nao se
tenha executado a simulacao com mais do que 4 processadores no esquema ”inter-no”,
os resultados parecem indicar que o principal obstaculo para um speedup linear com 8
processadores no esquema ”intra-no” foi a contencao no acesso a memoria.
Embora possa parecer que o ambiente PyMPI e sua interface dirigida a comandos nao
seja um ambiente ideal para simulacoes interativas, a flexibilidade de se incluir novos
comandos sem que se modifique muito o software original justifica seu uso. Em um sistema
implementado totalmente com um ambiente dirigido a eventos como o Motif, a inclusao
de uma nova funcionalidade leva a necessidade de alteracao da interface de usuario, algo
que nao e necessario no caso do PyMPI.
Ainda em relacao ao ambiente PyMPI, vale ressaltar que a impossibilidade de execucao
do motor de simulacao como threads nos nos de back-end limita a forma como parametros
da simulacao sao alterados, sendo assim necessario uma interrupcao da simulacao seguida
da alteracao de um parametro e finalmente a retomada da simulacao do ponto onde
87
ela havia parado. Uma alternativa a essa estrategia requer a modificacao do ambiente
PyMPI a fim de substituir o MPI como protocolo de envio de comandos para os nos de
back-end. Dessa forma uma segunda thread executaria em cada no back-end para receber
novos parametros de simulacao e alterar o comportamento do motor de simulacao, algo
semelhante ao servidor de steering do software Falcon.
Por fim, uma necessidade identificada nesse trabalho para implementacao futura e gera-
cao de frames da simulacao em paralelo. Nas simulacoes efetuadas foi possıvel realizar a
sıntese de imagem de cada frame num tempo menor que o intervalo de timesteps de cada
atualizacao das posicoes das partıculas. Entretanto, simulacoes envolvendo numeros de
partıculas ainda maiores podem exigir a paralelizacao da propria visualizacao, seja por
meio da paralelizacao da mesma utilizando um conjunto especıfico de nos da maquina
paralela ou seja particionando a propria sıntese da imagem entre os processadores a cargo
da simulacao, caso em que cada processador calcula, atualiza e visualiza as partıculas de
seu domınio local.
Nota-se que implementacoes paralelas interativas sao ainda limitadas e raras, face as suas
possibilidades em termos de viabilizar experimentos numericos, mesmo em Dinamica Mo-
lecular. Acredita-se que essa seja uma tendencia bem atual em diversas areas de pesquisa,
mas cujas implementacoes ainda encontram restricoes relativas as arquiteturas atualmente
disponıveis.
88
REFERENCIAS BIBLIOGRAFICAS
ACHARYA, A.; EDJLALI, G.; SALTZ, J. The utility of exploiting idle workstations for
parallel computation. In: ACM SIGMETRICS INTERNATIONAL CONFERENCE ON
MEASUREMENT AND MODELING OF COMPUTER SYSTEMS, 1997.
Proceedings... Seattle, 1997. 51
ALEN, M. P. Computer simulation of liquids. New York, USA: Oxford University
Press, 1993. 23
AMDAHL, G. The validity of the single processor approach to achieving large scale
computing capabilities. In: AMERICAN FEDERATION OF INFORMATION
PROCESSING SOCIETIES CONFERENCE. Proceedings... [S.l.], 1967. v. 30, p.
483–485. 44
AOYAMA, Y.; NAKANO, J. RS/6000 SP practical MPI programming. [S.l.]: IBM
Redbook, 1999. 34
BEAZLEY, D. M.; LOMDAHL, P. S. Extensible message passing application
development and debugging with Python. In: INTERNATIONAL PARALLEL
PROCESSING SYMPOSIUM. Proceedings... Salt Lake City, 1997. p. 650–655. 21, 70,
86, 87
BRUNNER, R. K. Versatile Automatic Load Balancing with Migratable
Objects. Illinois: [s.n.], January 2000. Disponıvel em:
<http://charm.cs.uiuc.edu/papers/RobertThesis.www/>. Acesso em: 2 jan. 2005.
49, 50
CAGIN, T.; JARAMILLO-BOTERO, A.; GAO, G.; III, W. G. Molecular mechanics and
molecular dynamics analysis of drexler merkle gears and neon pump. Nanotechnology,
v. 9, p. 143–152, 1998. 23
CONWAY, M. A multiprocessor system design. In: AMERICAN FEDERATION OF
INFORMATION PROCESSING SOCIETIES CONFERENCE. Proceedings... [S.l.],
1963. v. 24, p. 139–146. 37
DENG, Y.; PEIERLS, R. F.; RIVERA, C. An adaptive load balancing method for
parallel molecular dynamics simulations. Journal of Computational Physics,
Academic Press Professional, v. 161, n. 1, p. 250–263, 2000. 54
DENNIS, J. B.; HORN, E. C. V. Programming semantics for multiprogrammed
computations. Communications of the ACM, v. 26, n. 1, p. 29–35, 1966. 37
89
DOWD, K.; SEVERANCE, C. R. High performance computing. Sebastopol:
O’Reilly & Associates, 1998. 40
DUNCAN, R. A survey of parallel computer architectures. IEEE Computer, v. 23,
n. 2, p. 5–16, 1990. 33, 34
EISENHAUER, G.; GU, W.; KINDLER, T.; SCHWAN, K.; SILVA, D.; VETTER, J.
Opportunities and tools for highly interactive distributed and parallel
computing. College of Computing, Atlanta, GA 30332-0280: [s.n.], 1994. 19
FLYNN, M. J. Some computer organizations and their effectiveness. IEEE
Transactions on Computing, n. 9, p. 948–960, 1972. 33
FOSTER, I. Designing and building parallel programs. [S.l.]: Addison-Wesley,
1995. 37, 39
FOSTER, I.; KESSELMAN, C. The grid: blueprint for a new computing
infrastructure. [S.l.]: Morgan Kaufman Publishers, Inc., 1999. 36
GEIST, A.; BEGUELIN, A.; DONGARRA, J.; JIANG, W.; MANCHEK, R.;
SUNDERAM, V. S. PVM - Parallel Virtual Machine: a users’ guide and tutorial for
networked parallel computing. Cambridge, MA, USA: MIT Press, 1994. 40
GODFREY, M. D.; HENDRY, D. F. The computer as von Neumann planned it. IEEE
Annals of the History of Computing, v. 15, n. 1, p. 11–21, 1993. 34
GOULD, H.; TOBOCHNIK, J. An introduction to computer simulation
methods. [S.l.]: Addison-Wesley Publishing, 2003. 24, 25, 27, 28
GRAMA, A. Y.; GUPTA, A.; KUMAR, V. Isoefficiency: Measuring the scalability of
parallel algorithms and architectures. IEEE Parallel Distrib. Technol., IEEE
Computer Society Press, v. 1, n. 3, p. 12–21, 1993. ISSN 1063-6552. 44, 59
GRANATO, E.; BALDAN, M.; YING, S. Sliding friction in the frenkel-kontorova model.
Physics of Sliding Friction, Kluwer Academic Publishers, 1996. 23
GRAND challenges - science, engineering, and societal advances requiring networking
and information technology research and development. 2004. Disponıvel em:
<http://www.sc.doe.gov/ascr/200311_grand_challenges.pdf>. Acesso em: 2 jan.
2005. 33
GU, W.; EISENHAUER, G.; SCHWAN, K.; VETTER, J. S. Falcon: On-line monitoring
for steering parallel programs. Concurrency - Practice and Experience, v. 10, n. 9,
p. 699–736, 1998. 21, 69, 86
90
GUSTAFSON, J. L. Reevaluating amdahl’s law. Communications of the ACM,
v. 31, n. 5, p. 532–533, 1988. 44
HAN, J.; GLOBUS, A.; JAFFE, R.; DEARDORFF, G. Molecular dynamics simulations
of carbon nanotube-based gears. Nanotechnology, v. 8, p. 95–102, 1997. 19, 23
HEERMANN, D. W. Computer simulation methods. Heidelberg: Spring Verlag,
1990. 23
HEINO, P.; KASKI, K.; HaKKINEN, H. Molecular dynamics study of mechanical
properties of copper. Proceedings of American Physical Society - March
Meeting, 1998. 19, 23
HOCKNEY, R. W.; EASTWOOD, J. W. Computer simulation using particles.
London, England: Institute of Physics Publishing, 1988. 28
JABLONOWSKI, D.; BRUNER, J.; BLISS, B.; HABER, R. Vase: The visualization and
application steering environment. In: SUPERCOMPUTING. Proceedings... [S.l.],
1993. 21
KALE, L.; BHANDARKAR, M.; BRUNNER, R. Load balancing in parallel molecular
dynamics. In: INTERNATIONAL SYMPOSIUM ON SOLVING IRREGULARLY
STRUCTURED PROBLEMS IN PARALLEL. Proceedings... [S.l.], 1998. v. 1457, p.
251–261. 54
KARPLUS, M.; MCCAMMON, A. Molecular dynamics simulation of biomolecules.
Nature Structural Biology, v. 9, n. 9, p. 646–652, 2002. 19, 23
KASKI, K.; KURONEN, A.; ROBLES, M. Dynamics of dislocations in a
two-dimensional system. Computer Simulation Studies in Condensed Matter
Physics XIV, v. 98, p. 12–26, 1998. 19
KATZ, A. Principles of statistical mechanics. San Francisco: W. H. Freeman, 1967.
47
LINS, R.; BRIGGS, J.; STRAATSMA, T.; CARLSON, H.; GREENWALD, J.; CHOE,
S.; MCCAMMON, J. Molecular dynamics studies on the hiv-1 integrase catalytic
domain. Biophysical Journal, v. 76, n. 6, p. 2999–3011, 1999. 19, 23
MERIMAA, J.; PERONDI, L. F.; KASKI, K. An interactive simulation program for
visualizing complex phenomena in solids. Computer Physics Communications,
v. 124, p. 60–75, 2000. 20, 27, 76, 80, 81, 85, 87
91
MPI - A Message-Passing Interface Standard. 1994. Disponıvel em:
<citeseer.ist.psu.edu/519858.html>. Acesso em: 19 jan. 2005. 40
PFISTER, G. F. In search of clusters: the ongoing battle in lowly parallel computing.
2. ed. [S.l.]: Prentice Hall, 1998. 35
PLIMPTON, S. Fast parallel algorithms for short-range molecular dynamics. Journal
of Computational Physics, v. 117, p. 1–19, 1995. 15, 20, 21, 47, 48, 49, 61, 62, 82
QUINN, M. J. Parallel programming in C with MPI and OpenMP. [S.l.]:
McGraw-Hill, 2003. 59
RAPAPORT, D. C. The art of molecular dynamics simulation. [S.l.]: Cambridge
University Press, 1995. 20, 23, 24, 26, 28, 30, 31, 47, 49, 50, 52, 58, 67
. An introduction to interactive molecular dynamics simulations. Computer in
Physics, v. 11, p. 337–347, 1997. 20
RODRIGUES, E. R.; PRETO, A. J.; STEPHANY, S. A parallel engine for graphical
interactive molecular dynamics simulations. In: INTERNATIONAL SYMPOSIUM ON
COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING.
Proceedings... Foz do Iguacu, 2004. p. 150–157. 53
ROSSUM, G. van; JR., F. L. D. Extending and Embedding the Python
Interpreter. 2004. Disponıvel em: <http://docs.python.org/ext/ext.html>.
Acesso em: 2 jan. 2005. 74
STEEN, A. J. van der; DONGARRA, J. J. Overview of Recent Supercomputers.
2004. Disponıvel em: <http://www.top500.org/list/>. Acesso em: 2 jan. 2005. 51
STEPHANY, S.; PRETO, A. J.; GRANATO, E.; RIBEIRO, J. A. J. A parallel
implementation for a driven molecular dynamics algorithm. In: IBERIAN
LATIN-AMERICAN CONGRESS ON COMPUTATIONAL METHODS IN
ENGINEERING. Proceedings... [S.l.], 2003. 28
TANENBAUM, A. S. Organizacao estruturada de computadores. Rio de Janeiro,
RJ: Livros Tecnicos e Cientıficos, 2001. 33, 35, 36
TRAVIESO, G.; SLEATS, J. F. W. Implementacao de dinamica molecular em uma rede
de transputers. In: SIMPoSIO BRASILEIRO DE ARQUITETURA DE
COMPUTADORES E PROCESSAMENTO DE ALTO DESEMPENHO.
Proceedings... [S.l.], 1992. 30, 50
92
TUZUN, R. E.; NOID, D. W.; SUMPTER, B. G. Dynamics of a laser driven molecular
motor. Nanotechnology, v. 6, p. 52–63, 1995. 19
WANG, T. Molecular dynamics simulation on the Calculation of
thermophysical properties of argon crystal. Department of Mechanical
Engineering Purdue University, 2002. Disponıvel em: <http:
//widget.ecn.purdue.edu/~jmurthy/me608/projects/tianjiao-wang/twang.pdf>.
Acesso em: 19 jan. 2005. 27
93