DESENVOLVIMENTO DE UM SISTEMA ORIENTADO A OBJETOS PARA ANÁLISE ATRAVÉS DO MÉTODO DOS ELEMENTOS DISCRETOS

Humberto Carvalho Júnior Diogo Tenório Cintra Eduardo Setton da Silveira Sampaio humberto@lccv.ufal.br dtc@lccv.ufal.br eduardosetton@lccv.ufal.br Programa de Pós-Graduação em Engenharia Civil, Universidade Federal de Alagoas. Cidade Universitária, Campus A. C. Simões – 57.072-970 – Maceió – Alagoas, Brasil.

Resumo. Este trabalho apresenta uma estruturação e implementação de classes baseado no paradigma de orientação a objetos para análise de simulações computacionais utilizando-se o Método dos Elementos Discretos (MED). O MED apresenta-se atualmente como uma das principais técnicas numéricas para análise de problemas em meios descontínuos com comportamento estático ou dinâmico. Sua aplicação mostra-se bastante promissora na simulação de problemas que envolvem fenômenos de fragmentação ou fraturamento, impacto e colisão, cravação, entre outros. O principal objetivo da estruturação das classes é facilitar a manutenção e expansão do código computacional. Neste trabalho utilizou-se a linguagem de programação C++ para implementação computacional, apresentam-se exemplos de problemas utilizando-se o MED, visando destacar as principais características do sistema desenvolvido. Palavras Chave: Método dos Elementos Discretos, Programação Orientada a Objetos, Linguagem C++.

1. INTRODUÇÃO

Um paradigma de programação fornece (e determina) a visão que o programador possui sobre a execução do programa. Por exemplo, em programação orientada a objetos (POO) (Ricarte, 1995), programadores podem abstrair um programa como um conjunto de objetos que interagem entre si, enquanto em programação estruturada os programadores abstraem o programa como uma seqüência de funções executadas de modo seqüencial. Assim, a escolha do conceito de programação adequado ao desenvolvimento de sistemas computacionais torna-se um fato crucial na qualidade do software. Seja essa característica ligada ao desempenho e a robustez ou ainda quanto à facilidade à expansão, à manutenção e ao entendimento do código como um todo. Atualmente, o paradigma da programação orientada a objetos tem sido largamente empregado no desenvolvimento de vários sistemas computacionais voltados à engenharia, tendo inúmeros exemplos de implementações baseadas no Método dos Elementos Finitos (Cook et. al., 1989). Dentre outras se podem citar: Dubois-Pelerin (1992) abordando os conceitos de POO para o MEF e sua implementação; o programa de análise estrutural FEMOOP (Finite Element Method - Object Oriented Programming) (Martha et al, 1996) desenvolvido em C++ (Stroustrup, 1997) conjuntamente pelo Departamento de Engenharia Civil da PUC-Rio e pelo Laboratório de Mecânica Computacional da Escola Politécnica da USP; Archer et. al. (1999) propondo uma nova arquitetura para sistemas orientados a objetos (SOO) baseados no MEF; Lages et. al. (1999) apresentando a aplicação de elementos de viga e do contínuo de Cosserat na análise não-linear do MEF utilizando a filosofia da POO; Bastian & Li (2003) exibindo um gerador automático de malhas a partir de elementos finitos quadrangulares desenvolvido em C++; Pantalé (2005) mostrando a implementação em paralelo empregando a POO para a simulação de impactos a partir da formulação dinâmica do MEF. Recentemente, o trabalho Ferreira (2005), desenvolvido no Laboratório de Computação Científica e Visualização da UFAL, mostrou a implementação de um framework orientado a objetos para análise dinâmica geometricamente não linear de linhas de ancoragem e risers. Portanto, a estrutura geral das classes e as relações entre elas apresentados no trabalho citado, serviram de base para o desenvolvimento do presente trabalho pelo fato de ambos os sistemas possuírem características semelhantes e serem desenvolvidos no mesmo laboratório. O trabalho aqui apresentado exibe o processador do sistema DEMOOP (Discrete Element Method - Object Oriented Programming) construído sob a filosofia da POO. O Método dos Elementos Discretos (MED), proposto inicialmente por Cundall & Strack (1979), desponta com um procedimento efetivo para análise de meios descontínuos compostos por partículas materiais. Até o presente momento, são poucos os desenvolvimentos de sistemas orientados a objetos para o MED, podendo citar o trabalho Balev et. al. (2005) onde se apresenta o programa DEMMAT. Dessa maneira, busca-se com o emprego desse paradigma de programação no desenvolvimento do DEMOOP permitir sua fácil expansão, manutenção e entendimento do código sem comprometer o desempenho e a robustez. 2. MÉTODO DOS ELEMENTOS DISCRETOS

O MED tem sido empregado tradicionalmente no estudo de materiais granulares e rochosos, no entanto tem se tornado popular como um método para representar materiais sólidos e, sobretudo para o estudo de problemas de fluxo. Seu grande impulso ocorreu com a ascensão da capacidade de processamento de dados oriundos dos avanços da tecnologia da computação. Isto, em parte, está relacionado com a elevada necessidade de processamento de dados requerida.

O MED permite avaliar de maneira macroscópica o comportamento físico e mecânico do modelo estudado a partir do entendimento das propriedades mecânicas microscópicas dos elementos discretos e o comportamento da interação entre elas. O meio analisado é discretizado em uma série de partículas (elementos discretos) com propriedades mecânicas particulares e com geometrias definidas. A configuração do meio é investigada para cada intervalo de tempo definido para a análise, confrontando-se os elementos discretos entre si e atualizando as forças de contato entre os mesmos. Em função das forças de interação e ações externas atuantes nas partículas em um determinado instante de tempo, determina-se a configuração do meio no instante de tempo seguinte e, uma vez investigada as peculiaridades de cada intervalo de tempo, determina-se o comportamento dinâmico do meio estudado. De uma forma geral, o equacionamento do método resume-se na aplicação da Segunda Lei de Newton às partículas, levando ao cálculo dos deslocamentos devido às forças que agem nelas, e na aplicação das Leis de Força-Deslocamento nos contatos, que calculam as forças nos contatos devido aos deslocamentos das partículas. Assim cada partícula possui uma equação de movimento descrita da seguinte forma:

)(),(),(),( int tFuuFuuFuuFuCuM extelemcont +−+=+ &&&&&&&&&&&& (1) onde M e C são respectivamente as matrizes de massa e amortecimento da partícula. A parcela total de forças é composta pelo contato entre as partículas (Fcont), pelas forças geradas através dos elementos lineares de vínculo entre duas partículas (Felem), pelos esforços internos (Fint) e pelas ações externas aplicadas (Fext). 3. DESCRIÇÃO DO SISTEMA DEMOOP

O sistema DEMOOP é dividido em três partes distintas responsáveis pelas atividades de pré-processamento, análise e visualização, o que oferece algumas vantagens vinculadas ao relacionamento entre o sistema e os usuários ou programadores. A comunicação entre as partes é feita através de arquivos com uma formatação previamente determinada. Desta forma, os processos se tornam independentes e acabam facilitando o seu manuseio. Para o usuário esta divisão oferece conveniência, uma vez que o mesmo pode reutilizar dados de uma análise para a formulação de uma outra com características diferentes, sem a desvantagem de perder os resultados da primeira. Já para os programadores, a divisão fornece um ambiente de trabalho onde não há mistura de características peculiares de programação de cada uma das partes. A Figura 1 apresenta um ilustração de como ocorre a comunicação entre as partes.

Figura 1 – Fluxograma de análise - DEMOOP.

Pós- Processador

Usuário

Pré- Processador

Processador

Arquivo de Entrada

Arquivo de Saída

Dados de Análise Resultados

3.1. Pré-Processamento

A atividade de pré-processamento corresponde à etapa inicial em uma simulação computacional. Nesta fase busca-se, através do estabelecimento de um modelo numérico, uma maneira de traduzir informações de problemas reais em dados que o método empregado para a solução numérica proposta possa entender e avaliar. Em uma análise através do MED, por exemplo, a etapa de pré-processamento define informações relativas ao meio descontínuo estudado. São definidas geometrias e parâmetros para os materiais que compõe as partículas em estudo, bem como condições de restrições, informações referentes aos algoritmos de busca por contato e de integração temporal, dentre outros. Em geral, a utilização de programas computacionais dotados de ambientes de interface gráfica costuma ser mais amigável ao usuário durante este processo, uma vez que permite uma visualização incrementada do modelo computacional que se deseja construir. Apresenta-se, de acordo com a Figura 2, o protótipo de um programa responsável pela geração dos arquivos de análise requerido pelo processador DEMOOP. O programa permite a partir da definição de geometrias das partículas, dos parâmetros dos materiais envolvidos e de outros dados referentes à análise, a construção de um modelo numérico com as especificações necessárias para a sua simulação posteriormente realizada.

Figura 2 – Pré-Processador.

3.2. Processamento

O algoritmo de solução do MED apresenta geralmente uma rotina de repetição de processos conforme ilustrado na Figura 3. Estes processos incluem a checagem de contatos entre partículas, a determinação das forças atuantes, a análise dos elementos lineares de vínculo que podem ser acoplados às partículas e a integração das velocidades e posições a partir das acelerações previamente determinadas. Observa-se que, uma vez asseguradas as ações externas atuantes e as condições iniciais para o problema, o processo descrito acima descreve o comportamento dinâmico do meio.

Figura 3 – Processo de análise.

A implementação computacional deste módulo é realizada com o uso da linguagem de programação C++. Esta escolha baseia-se no pressuposto de que o código do programa possa embasar futuras implementações e de que ele possa ser facilmente expandido, não requerendo mudanças significativas no seu conteúdo. Desta forma o paradigma de POO embutido na linguagem mostra-se útil. Outros fatores com respaldo na escolha da linguagem são: a natureza compilada e o gerenciamento de memória utilizado no programa. Estes últimos permitem um ganho de desempenho significativo e necessário para a viabilização de análises robustas que possam ser executadas. 3.3. Pós-Processamento

A tarefa de visualização das análises é feita a partir do software DEMOOP View. Esta aplicação consiste em um ambiente de interface gráfica nos quais os dados fornecidos pelo programa de análise (DEMOOP) podem ser interativamente apresentados ao usuário. Sua principal tarefa consiste na transformação do arquivo de saída fornecido pelo programa da análise (Figura 1) em dados gráficos de fácil manuseio. A partir deste software, o usuário pode, por exemplo, esboçar animações do processo de análise, montar gráficos a partir de propriedades de partículas de interesse específicos, tais como: posições, vetores de velocidade, acelerações, dentre outros. Para tanto, faz-se necessário a utilização de um sistema gráfico que permita o desenho das entidades a serem visualizadas. Utiliza-se com este fim, o sistema OPENGL, Woo et. al. (2003). A implementação do pós-processador foi feita também utilizando a linguagem computacional C++, utilizando o paradigma da orientação a objetos. Tal escolha baseia-se no pressuposto de que novas funcionalidades possam ser incorporadas ao programa no futuro, e que assim sendo, esta tarefa esteja facilitada em virtude da natureza do código base. São empregadas ainda bibliotecas que facilitam o processo de formulação da interface gráfica, bem como do manuseio do sistema gráfico utilizado, dentre elas pode-se citar: IUP, VIS e VGL.

Levy et. al. (1996) apresenta o IUP como uma ferramenta portátil para a construção de interface gráfica com usuários. Esta permite a criação de programas que podem ser executados em diferentes sistemas operacionais sem qualquer modificação do código, uma vez que usa os elementos de interface nativos. Dentre suas principais vantagens estão o alto desempenho, uma vez que ele trabalha com o uso de elementos de interface nativos do sistema operacional, e o fácil aprendizado pelo usuário (programador), devido à simplicidade de suas funções. O IUP foi desenvolvido pelo grupo Tecgraf/PUC-Rio em parceria com a Petrobras/CENPES. As bibliotecas VIS e VGL são responsáveis pela comunicação com o sistema gráfico. Estas permitem tratar com facilidade aspectos relacionados com o desenho dos objetos, bem como do processo de manipulação de câmeras, envolvidas. Isto permite que o usuário trate de maneira implícita peculiaridades relacionadas com o gerenciamento otimizado da renderização de formas geométricas e da manipulação de matrizes de transformação geométricas. A Figura 4 ilustra a aplicação DEMOOP View em uma análise de um muro de contensão de talude.

Figura 4 – DEMOOP View.

4. ORGANIZAÇÃO DE CLASSES

São definidas então classes, que quando integradas na aplicação responsável pelo processo descrito na Figura 5, permitem a modelagem do problema proposto. Uma classe pode ser entendida como um conjunto de atributos e métodos que permitem a definição de um objeto sobre a qual a mesma caracteriza e opera. Os atributos são responsáveis pela caracterização do objeto definido pela classe. Em uma implementação computacional os atributos correspondem às variáveis que armazenam informações do objeto. Já métodos são funções peculiares que operam sobre estes atributos. Em virtude do paradigma de programação orientado a objetos utilizado, faz-se necessário o estabelecimento de um esquema de classes que permita à aplicação a ser desenvolvida uma facilidade de manuseio dos dados dos “objetos” estabelecidos. Isto geralmente é obtido

quando existe uma boa correlação entre as entidades tratadas e suas respectivas classes. Desta forma, o reuso do código e o respectivo entendimento do mesmo se torna menos oneroso. A visualização do esquema de classes proposto pode ser feita com facilidade, a partir do diagrama de classes da aplicação desenvolvida. Este diagrama aponta a maneira com a qual as classes se interligam, suas relações de extensão (herança), dentre outros. Para a representação do diagrama de classes da aplicação DEMOOP (Figura 5), utiliza-se um padrão de linguagem comumente utilizado para este fim. Trata-se do padrão UML (Unified Modeling Language). Segundo Rumbaugh et al. (2000) UML é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software. Essa linguagem é um sistema gráfico de notação voltada à modelagem de sistemas computacionais, que incorpora os conceitos da programação orientação a objetos. De acordo com o diagrama da Figura 5, observa-se a presença de tipos que correspondem as abstrações das entidades que compõem um modelo em elementos discretos a partir da classe Model. Nesta, estão presentes as partículas através da classe Particle, onde uma determinada partícula é definida a partir de uma geometria (classe Geometry), do material que a compõe (classe Material) e das condições de contorno ou vinculação (classe Support). A superclasse Geometry fornece subsídio às partículas para que as mesmas possuam uma forma geométrica definida e possam consultar as informações necessárias quanto aos aspectos geométricos, seja esta forma plana ou tridimensional, de acordo com as subclasses Geometry2D e Geometry3D. Até o presente momento encontram-se implementadas as classes concretas Circle e Polygon extendidas da Geometry2D, bem como também no caso tridimensional criada a partir da classe Geometry3D a subclasse Sphere. A classe Support é responsável pelo controle dos possíveis vínculos aplicados aos seis graus de liberdade de uma determinada partícula, assim, caso necessário, é possível simplesmente travar o grau de liberdade na sua configuração inicial ou ainda prescrever estado cinemático do mesmo com o uso da superclasse Prescribed. Dentre as opções de prescrição cinemática tem-se o controle de deslocamento a partir da subclasse Displacement e o controle de velocidade a partir da subclasse Velocity. Atrelada ainda a superclasse Prescribed, é possível utilizar uma função ao longo do tempo (superclasse Function) para descrever o comportamento cinemático, seja ele de deslocamento ou de velocidade. Os carregamentos são aplicados nas partículas com uso da classe AppliedLoad, para tanto esta classe obtém a informação do carregamento específico da superclasse Load aplicando-o diretamente na instância da classe Particle. Análogo ao processo de prescrição cinemática, também é possível atrelar a aplicação do carregamento através da superclasse Load, a utilização de uma função temporal para aplicação de um carregamento variável com o tempo. Descrito anteriormente no equacionamento do MED, pode-se fazer o uso de elementos de vínculo ligando partículas às outras, de modo que exista uma restrição entre ambas. A superclasse Element tem como função definir o comportamento desses elementos de vínculo. Até então, existe implementado o elemento de treliça espacial com comportamento visco-elástico localizado na subclasse Truss. No intuito de obter os contatos entre as partículas, ou seja, as sobreposições geométricas utiliza-se a superclasse ContactSearch. Esta apresenta suas classes derivadas DirectSearch e DirectMapping que possuem a mesma função, encontrar todos os contatos entre as partículas e calcular as forças proveniente dos mesmos utilizando a classe Interaction. Tais forças podem ser calculadas empregando-se modelos constitutivos distintos para a modelagem da interface de contato através da superclasse ConstitutiveModel, sendo especificamente extendida pelas subclasses Hooke, Kelvin e KelvinCoulomb.

Figura 5 – Diagram

a de classes do DEM

OO

P.

AppliedLoad

Load

CenterDifference

Circle

ConstitutiveModel

ContactSearch

Demoop

DirectChecking

DirectMapping

Displacement

Element

Force

Function

Geometry

Geometry2D Geometry3DHarmonic Hooke

Interaction

Kelvin

KelvinCoulomb

Material

MegAlpha

Model

Particle

Piecewise

Polygon

Prescribed

SphereStepCosine

Support

TimeIntegration

Truss

Velocity

1

1

1

1..*

1

0..*

1

1

1..* 1

1

2

1..*

1

1 1

1

1

1..*1

1..*

0..6

1..*

0..1

1

0..*

1..*

1

1 1

1..*

0..1

5. DESCRIÇÃO DAS CLASSES

A seguir são apresentadas características das principais classes envolvidas na construção da aplicação DEMOOP, tais como seus principais atributos, métodos e relações de classes. Isto permite uma visualização mais focada da integração da aplicação com o processo de análise do MED descrito anteriormente. 5.1. Classe Demoop

Conforme citado anteriormente, o papel desempenhado pelo processador DEMOOP é o de transformar as informações de análise fornecidas pelo programa de pré-processamento, mais especificamente dos dados do arquivo de entrada, em um modelo numérico sob o qual o mesmo possa operar. Desta forma faz-se necessário a construção de um objeto que armazene todas as informações referentes à caracterização do modelo a ser estudado e de um objeto que possa fazer o tratamento dinâmico requerido pelo MED. A classe Demoop é a responsável por este feito. Esta dispõe de métodos que são responsáveis pela leitura dos dados de análise do arquivo de entrada (LoadFile), pela construção do modelo numérico (LoadModel) e do processo de integração temporal a ser utilizado (IntegrationBuild), pelo controle de solução do processo (Solve) e pela geração dos resultados de análise em arquivos com formatação previamente determinada (PrintFile). A Figura 6 apresenta o diagrama da classe Demoop, destacando seus principais atributos e métodos.

Demoop Model * model TimeIntegration * timeIntegration LoadFile( ) LoadModel( ) IntegrationBuild( ) Solve( ) PrintFile( )

Figura 6 – Diagrama da classe Demoop.

5.2. Classe TimeIntegration

O tratamento do processo de integração numérica temporal é realizado através da superclasse TimeIntegration. Com este propósito, a mesma conta com o auxílio de métodos virtuais puros que obrigam às classes derivadas o cálculo dos vetores de forças internas e externas e atualização das propriedades de massa (ComputeFextFintMass), bem como dos deslocamentos, velocidades e acelerações (ComputeDisVelAccel). Estes cálculos são realizados de maneira específica, de acordo com a formulação do método utilizado. O controle do processo de integração é realizado invocando-se o método ComputeStep e informando ao mesmo o intervalo de tempo a ser integrado. Dentre as subclasses responsáveis por este papel, estão as que empregam o Método das Diferenças Centrais (classe CenterDifference) e o Método Explícito Generalizado - α (classe MegAlpha), conforme observa-se na Figura 5. O diagrama da classe TimeIntegration é ilustrado na Figura 7.

TimeItegration Model * model double * internalForce double * externalForce double * mass double * displacement double * velocity double * acceleration ComputeStep( ) ComputeFextFintMass( ) ComputeDisVelAccel( )

Figura 7 – Diagrama da classe TimeIntegration.

Classe CenterDifference. Esta classe representa o algoritmo de integração temporal explícito conhecido como o Método das Diferenças Centrais (Krysl & Belytschko, 1998). Na Figura 8 pode ser visto o diagrama da classe CenterDifference.

CenterDifference ComputeFextFintMass( ) ComputeDisVelAccel( )

Figura 8 – Diagrama da classe CenterDifference.

Classe MegAlpha. Esta classe representa o algoritmo de integração no tempo explícito conhecido como o Método Explícito Generalizado – α proposto por Hulbert & Chung (1996). Os atributos observados na presente classe são inerentes ao algoritmo em questão. Na Figura 9 pode ser observar o diagrama da classe MegAlpha.

MegAlpha double rhob double am double b double lamb ComputeFextFintMass( ) ComputeDisVelAccel( )

Figura 9 – Diagrama da classe MegAlpha.

5.3. Classe Model

Consiste na classe responsável pela caracterização do modelo numérico durante todo o processo de análise. Desta forma, o seu grau de inter-relacionamento com as demais classes, evidenciado no diagrama de classes da Figura 5, fica justificado. Dentre os seus principais atributos estão: as partículas de elementos discretos que compõe o meio descontínuo

estudado, os elementos de ligação que eventualmente podem existir fazendo a interação entre as partículas, os carregamentos aplicados e o algoritmo de busca de contatos empregado na análise. A classe Model dispõe, dentre outros, de métodos responsáveis pela atualização das propriedades de massa do sistema (ComputeMass), cálculo das forças internas (ComputeInternalForce) e externas (ComputeExternalForce), necessários durante o processo de integração temporal. A Figura 10 ilustra o diagrama da classe em questão exibindo seus principais atributos e métodos.

Model ContactSearch * contactSearch Particle ** particles Element ** elements AppliedLoad ** loads ComputeMass( ) ComputeInternalForce( ) ComputeExternalForce( )

Figura 10 – Diagrama da classe Model.

5.4. Classe Particle

A representação do meio descontínuo é feita a partir da classe Particle. Esta classe estabelece uma definição formal para as entidades sobre qual o MED opera. Para a caracterização destas entidades são necessários atributos que possam revelar aspectos vinculados à geometria (classes Geometry2D e Geometry3D), ao material que as constituem (classe Material), bem como a informações referentes à suas localizações no espaço, seus estados de rotações e velocidades, e de condições de restrição (classe Support). Os métodos UpdatePosition e SetVelocity são utilizados para atualizar os deslocamentos e velocidades da partícula, são geralmente chamados dentro dos métodos das classes responsáveis pela integração numérica no tempo. Pode-se observar os principais métodos e atributos da classe Particle na Figura 11.

Particle double * position double * velocity Support * support Geometry * shape Material * parameters UpdatePosition( ) SetVelocity( ) GetPosition( ) GetVelocity( )

Figura 11 – Diagrama da classe Particle.

5.5. Classe ContactSearch

Conforme abordado anteriormente, faz-se necessário, a cada interação do algoritmo de integração temporal do modelo, a checagem de contatos entre partículas do domínio analisado. Visando o cumprimento desta requisição, estabelece-se uma superclasse (Figura 12) de onde irão herdar outras classes que tratem este problema. Estas devem ser capazes de, para cada interação do algoritmo, fazer o teste de intersecção de geometria das partículas para os casos em que se julga necessário fazê-lo. Com este fim, estabelece-se o método virtual puro Check onde cada classe derivada deve confrontar as partículas com possibilidade de contato e determinar se este último ocorre de fato. Do diagramas de classes da Figura 5 observa-se as duas classes implementadas no Demoop e responsáveis por este processo: DirectChecking (Checagem Direta) e DirectMapping (Mapeamento Direto). Uma vez identificado o contato entre partículas, o mesmo deve ser tratado. Isto é feito com o auxílio da classe Interaction, que tomando como base o modelo constitutivo estabelecido para representar o contato (classes Hooke, Kelvin e KelvinCoulomb). Este irá ditar as regras de imposição de forças às partículas envolvidas neste instante de modo a impedir que haja sobreposição de matéria em um mesmo local do espaço. A Figura 12 representa o diagrama da classe em questão.

ContactSearch Interaction * interaction Check( )

Figura 12 – Diagrama da classe ContactSearch.

Classe DirectCheck. Esta classe representa o algoritmo responsável pela detecção da existência de contatos a partir da combinação de todos os pares possíveis de partículas existentes na análise, realiza-se assim a checagem de interseção geométrica entre elas. O diagrama da classe na Figura 13 apresenta apenas o método Check, que é responsável pela checagem e obtenção dos contatos entre as partículas do modelo.

DirectCheck Check( )

Figura 13 – Diagrama da classe DirectCheck.

Classe DirectMapping. Esta classe representa o algoritmo responsável pela detecção da existência de contatos a partir do mapeamento direto baseado na divisão do domínio em células. Tal estratégia consiste em dividir o domínio estudado em células do mesmo tamanho, de modo que a maior de todas as partículas esteja totalmente inserida dentro de uma única célula. Dessa maneira, garante-se que somente existe contato geométrico de uma determinada partícula com outra qualquer se as mesmas estiverem em células adjacentes ou ainda em uma célula comum. Da mesma forma da classe anterior, o método Check obtém os contatos entre as partículas do modelo, porém utiliza a estratégia baseada na divisão celular do domínio. Assim, o diagrama da classe na Figura 14 apresenta também apenas o método Check.

DirectMapping Check( )

Figura 14 – Diagrama da classe DirectMapping.

5.6. Classe Geometry

Esta superclasse representa as possíveis formas geométricas que podem ser empregadas para definição da geometria das partículas. De acordo com o diagrama exibido na Figura 15 pode-se ver os métodos e atributos que servem a todas as subclasses que extendem Geometry. Destaca-se o método virtual puro GetBoundBox que é implementado de acordo com cada tipo de geometria concreta definida.

Geometry BoundBox * boundBox double maxDimension GetBoundBox( ) GetMaxDimension( )

Figura 15 – Diagrama da classe Geometry.

Classe Geometry2D. Abstração empregada para representar as formas planas, possuindo assim características peculiares às mesmas, tais como área e inércia das formas planas. A partir da Figura 16 visualiza-se os atributos e métodos de Geometry2D. O método virtual puro IntersectionTest é implementado nas classes que extendem Geometry2D, ao exemplo das classes Circle e Polygon. Tal método possui a função de detectar o contato geométrico entre as formas planas e é invocado dentro do método Check definido na superclasse ContactSearch.

Geometry2D double area double inertia IntersectionTest( ) GetBoundBox( ) GetArea( ) GetInertia( )

Figura 16 – Diagrama da classe Geometry2D.

Classe Geometry3D. Representação utilizada para as formas tridimensionais e de maneira análoga a classe Geometry3D possui atributos inerentes ao seu comportamento tais como volume e inércia. Na Figura 17 são mostrados os atributos e métodos de Geometry3D. O método virtual puro IntersectionTest é também implementado nas classes que extendem

Geometry3D e possui o mesmo objetivo do método de mesmo nome citado na classe exibida anteriormente.

Geometry3D double volume double inertia IntersectionTest( ) GetBoundBox( ) GetVolume( ) GetInertia( )

Figura 17 – Diagrama da classe Geometry3D.

5.7. Classe Material

Na classe Material, podem ser definidas as propriedades dos materiais associadas às partículas do modelo. São eles, o peso específico, módulo de elasticidade, coeficiente de Poisson e ainda todos os parâmetros que caracterizam a interface de contato tais como, rigidez normal, amortecimento normal, rigidez tangencial, amortecimento tangencial e coeficiente e atrito. Tais propriedades são consultadas pela classe ConstituveModel no cálculo das forças provenientes do contato entre as partículas. Na Figura 18 apresenta-se o diagrama da classe Material.

Material double density double E double poisson double Kn double Cn double Kt double Ct double ni GetDensity( )

... GetNi( )

Figura 18 – Diagrama da classe Material.

5.8. Classe Support

A classe Support possui a função de gerenciar os possíveis vínculos que podem ser aplicados aos graus de liberdade das partículas. Assim, com o uso da classe Support ativando ao menos um dos graus de liberdade da partícula, é possível prescrever o comportamento cinemático a partir da superclasse Prescribed optando pelas subclasses Displacement ou Velocity. Tal funcionalidade é disponibilizada através do método SetConstraint, para aplicar um vínculo é necessário informar a esse método um grau de liberdade e uma referência para um objeto da classe Presc. É possível também informar essa referência como sendo nula que

automaticamente a classe Support entende que se trata de um grau de liberdade fixo, ou seja, sem movimento prescrito. A Figura 19 ilustra os métodos e os atributos da classe em pauta.

Support int * supp Prescribed ** presc GetSupp( ) GetPresc( ) SetFree( ) SetConstraint( )

Figura 19 – Diagrama da classe Support.

5.9. Classe Prescribed

Como citado anteriormente, a superclasse Prescribed é associada à classe Support para prescrever o movimento de um único grau de liberdade. Para tanto se faz o uso de uma função (classe Function) que controla o parâmetro value da classe. E em função da subclasse instanciada (classe Displacement ou Velocity) altera-se o comportamento cinemático do grau de liberdade em questão, de maneira compatível com a mesma, através do método virtual puro ComputePresc.

Prescribed double value Function * func ComputePresc( )

Figura 20 – Diagrama da classe Prescribed.

Classe Displacement. Refere-se à subclasse que prescreve os deslocamentos de um determinado grau de liberdade por meio do método ComputePresc, ao qual esta é forçado a implementar de acordo com a definição da superclasse Prescribed. Portanto, uma vez definido os deslocamentos, é realizado o cálculo das velocidades e acelerações em função do mesmo. A Figura 21 exibe as informações da classe em questão.

Displacement int dof ComputePresc( )

Figura 21 – Diagrama da classe Displacement.

Classe Velocity. Utilizada também para prescrever a cinemática de um determinado grau de liberdade, controlando a velocidade a partir da implementação do método ComputePresc. De forma semelhante à classe Displacement, a partir da definição da velocidade para o grau de liberdade, calcula-se os correspondentes deslocamentos e acelerações. A Figura 22 ilustra as informações e funcionalidades presentes na classe em pauta.

Velocity

int dof ComputePresc( )

Figura 22 – Diagrama da classe Velocity.

5.10. Classe AppliedLoad

Responsável pela associação entre carregamentos aplicados e partículas e o tratamento de forças envolvidos nesta associação realizado pelo método ComputeLoad. O diagrama da classe AppliedLoad é apresentado na Figura 23.

AppliedLoad int idParticle Load * load ComputeLoad( )

Figura 23 – Diagrama da classe AppliedLoad.

5.11. Classe Load

Superclasse que caracteriza os carregamentos que atuam sobre o modelo numérico tratado. Sua função principal é calcular as forças resultantes destes carregamentos. Dentre seus principais atributos estão: o valor do carregamento e a função de tempo a ser utilizada na sua aplicação deste carregamento ao modelo. O diagrama da classe Load é apresentado na Figura 24.

Load double value Function * func ComputeLoad( )

Figura 24 – Diagrama da classe Load.

Classe Force. Classe que caracteriza as forças atuantes sobre o modelo. Esta classe possui um atributo que especifica o grau de liberdade sob o qual a força opera e um método que calcula a força resultante, conforme apresentado no diagrama da Figura 25.

Force int dof ComputeLoad( )

Figura 25 – Diagrama da classe Force.

5.12. Classe Function

Corresponde à superclasse das funções de tempo. Sua utilização permite a adoção de “funções rampas” quase sempre necessárias na criação de instância da classe de carregamento (Load) e prescrições (Prescribed). As funções rampas em geral são úteis quando se deseja aplicar um carregamento ao modelo de maneira gradativa e consequentemente menos descontínua. Esta classe possui um método virtual puro que obriga as classes derivadas a fornecer o valor da imagem da função correspondente para um dado valor do seu domínio (Figura 26). As classes Harmonic, StepCosine e Piecewise são exemplos característicos de aplicações de funções rampas e estas portanto derivam da classe Function.

Function GetValue( )

Figura 26 – Diagrama da classe Function.

Classe Harmonic. Sub-classe de Function e que implementa uma função harmônica definida pela sua amplitude, fase, período e pelo valor médio sob o qual a função oscila. A Figura 27 apresenta seus principais atributos e métodos.

Harmonic double a double w double phi double v0 double ti double tf GetValue( )

Figura 27 – Diagrama da classe Harmonic.

Classe StepCosine. Esta é a classe que implementa a função step cosine. Sua utilização permite o estabelecimento de uma função de comportamento co-senoidal a um dado intervalo definido pelos valores de domínio “ti” e “tf” e pelos valores de imagem “vi” e “vf”. A representação dos atributos e métodos desta classe é apresentada na Figura 28.

StepCosine double ti double tf double vi double vf GetValue( )

Figura 28 – Diagrama da classe StepCosine.

Classe Piecewise. Classe que permite a definição de funções lineares por trechos. Em sua construção faz-se necessário o estabelecimento do número de pontos que definem os trechos das funções e os seus respectivos pares domínio-imagem. A Figura 29 apresenta os atributos e métodos desta classe.

Piecewise int points double * time double * height GetValue( )

Figura 29 – Diagrama da classe Piecewise.

5.13. Classe Element

Formaliza os objetos definidos como elementos de vínculo entre partículas. Estes permitem o estabelecimento de relações específicas entre as partículas do modelo estudado. O tratamento destas relações particulares é feito a partir de um método virtual puro (Figura 30) implementado de maneira conveniente pelas sub-classes de Element.

Element Analysis( )

Figura 30 – Diagrama da classe Element.

Classe Truss. Sub-classe de Element que faz o tratamento dos elementos de ligação entre partículas considerando uma relação entre forças e deslocamentos de acordo com o material adotado. Esta classe permite que se estabeleça um vínculo fictício conectando duas partículas e que impõe forças a ambas à medida que estas mudam a sua configuração ao longo do tempo. O diagrama da classe Truss é apresentado na Fig. 31.

Truss bool reactionCompression double L0 Material * parameters Particle * particle1 Particle * particle2 Analysis( )

Figura 31 – Diagrama da classe Truss.

5.14. Classe Interaction

Trata-se da entidade responsável pelo tratamento do contato entre as partículas, quando o mesmo é caracterizado. A partir da constatação do contato entre ambos os elementos

discretos, a classe em questão tem o papel de identificar os deslocamentos e velocidades relativas do passo em questão da análise e transformá-los em forças de contato utilizando a classe ConstitutiveModel a partir de suas derivadas, tanto para as forças de contato normais quanto as tangenciais. A Figura 32 mostra o diagrama da classe Interaction.

Interaction ConstitutiveModel * normal ConstitutiveModel * tangent CheckParticles( )

Figura 32 – Diagrama da classe Interaction.

5.15. Classe ConstitutiveModel

Possui a função de transformar os deslocamentos e velocidades relativas, provenientes de pares de partículas que estejam em contato, em informações de forças. Apresenta as subclasses concretas Hooke, Kelvin e KelvinCoulomb que implementam o método virtual puro ComputeForce (Figura 33) de acordo com os modelos reológicos de mesmo nome.

ConstitutiveModel ComputeForce( )

Figura 33 – Diagrama da classe ConstitutiveModel.

6. EXEMPLOS

6.1. Uso do Código

Neste tópico procura-se exemplificar situações de uso do código implementado, a partir da simples criação de instâncias de algumas das classes implementadas e exibidas anteriormente. Apresenta-se na Figura 34, uma maneira geral de se criar uma instância da classe Demoop, responsável pela construção das classes Model e TimeIntegration através das chamadas dos métodos LoadModel e IntegrationBuild.

Figura 34 – Manipulação da classe Demoop.

// Instância da classe Demoop Demoop * demoop = new Demoop("c:\duto.data", "c:\duto.out"); // Leitura do arquivo de entrada demoop->LoadFile(); // Construção do modelo a partir do arquivo demoop->LoadModel(); // Construção do algoritmo de integração a partir do arquivo demoop->IntegrationBuild(); // Solução do modelo demoop->Solve();

A construção de uma partícula (objeto da classe Particle) se dá primeiramente pela geração dos objetos que o compõem, e em seguida, a partir da chamada do seu construtor, são passadas as referências como atributos. É possível criar uma partícula com as linhas do pseudocódigo exibido na Figura 35.

Figura 35 – Criação da classe Particle.

6.2. Exemplo de Aplicação

Neste exemplo do potencial de aplicação do método, simula-se o comportamento mecânico do sistema solo-duto submetido a uma carga de serviço (q) e ao peso próprio das camadas de recobrimento de acordo com o modelo idealizado na Figura 36. Investiga-se o estado de deformações do duto pelo efeito de alterações no parâmetro mecânico que se refere à rigidez do duto, assim como na adoção de valas com larguras distintas no intuito de avaliar o efeito do confinamento lateral nas deformações do duto enterrado.

Figura 36 – Modelo do sistema solo-duto.

As propriedades mecânicas dos contatos entre as partículas empregadas na modelagem do solo e do duto são descritas na Tabela 1.

qq

H

L

D

... // Criação de uma geometria plana circular Geometry * geom = new Circle(1.5); // Criação de um material Material * mat = new Material(1, 1.8, 2E3, 0.3, 1.5, 1.2, 1, 0.8, 0.65); // Criação de um vetor de posições double pos[6]; pos[1] = 0; pos[2] = 0; pos[3] = 0; pos[4] = 0; pos[5] = 0; pos[6] = 0; // Construção de uma partícula Particle * part = new Particle(pos, geom, mat); // Criação de vínculo restringindo o grau de liberdade 1 Support * supp = new Support(); supp->SetConstraint(1); // Associação da restrição à partícula Part->SetSupports(supp); ...

Tabela 1 – Modelo do sistema solo-duto.

Propriedades Mecânicas / Meio Duto Solo

)/( mkNkn 1500 1200

)/( mskNcn ⋅ 95 85

)/( mkNkT 115 75

)/( mskNcT ⋅ 11 7 µ 0.6 0.5

Nas partículas que compõem o duto são adotados ainda elementos lineares de natureza visco-elástica para a criação de vínculos permanentes no intuito de preservar a forma geométrica do duto (Figura 37). As propriedades mecânicas destes elementos de vínculo são listadas na Tabela 2, onde Lk é a rigidez axial e Lc o amortecimento viscoso do elemento linear.

Tabela 2 – Propriedades mecânicas dos elementos lineares.

Análises )/( mMNkL )/( msMNcL ⋅ Duto Flexível 50 15 Duto Rígido 200 60

A vala idealizada neste exemplo apresenta larguras L1=2m e L2=4m, altura H=2.8m, possuindo um duto de diâmetro D=0.8m.

Figura 37 – Modelagem do duto empregando partículas e elementos lineares.

Admitindo-se uma carga de serviço q=30kN/m2, são mostradas as configurações deformadas finais do sistema solo-duto para as análises: vala curta com duto rígido e flexível (Figura 38), vala larga com duto rígido e flexível (Figura 39), respectivamente.

Figura 38 – Deformada da vala curta com duto rígido e flexível.

Figura 39 – Deformada da vala larga com duto rígido e flexível.

A seguir são apresentados gráficos das medidas de deformação interna do duto, vertical (Figura 40) e horizontal (Figura 41) respectivamente, ambas em função da fração da carga de serviço total aplicada.

Figura 40 – Gráfico da deformação vertical do duto.

Figura 41 – Gráfico da deformação horizontal do duto.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1-0.02

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

Def

orm

ação

Hor

izon

tal

Fração da Carga Total

Vala Curta - Duto FlexívelVala Curta - Duto RígidoVala Larga - Duto FlexívelVala Larga - Duto Rígido

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1-0.25

-0.2

-0.15

-0.1

-0.05

0

0.05

0.1

Def

orm

ação

Ver

tical

Fração da Carga Total

Vala Curta - Duto FlexívelVala Curta - Duto RígidoVala Larga - Duto FlexívelVala Larga - Duto Rígido

7. CONSIDERAÇÕES FINAIS

Este trabalho apresenta o desenvolvimento de um ambiente computacional direcionado à análise de problemas analisados através de simulações numéricas do Método dos Elementos Discretos (MED). Este é construído de acordo com os conceitos da filosofia de programação orientada a objetos, o que permite que o sistema seja constantemente ampliado a partir de alterações planejadas e bem orientadas. Em linhas gerais, optou-se pela adoção do paradigma da POO no desenvolvimento de um sistema computacional para engenharia baseado no MED, a arquitetura adotada mostrou-se adequada no desenvolvimento do programa DEMOOP, conferindo ao mesmo facilidade tanto no uso, quanto na manutenção e adição de novas funcionalidades. A filosofia da POO empregada permite um melhor aproveitamento das ferramentas computacionais disponibilizadas de trabalhos anteriores, de acordo com a reutilização de algumas classes adotadas neste trabalho. Busca-se ainda uma divisão do trabalho entre os que desenvolvem o sistema, de maneira que não se necessite conhecer o programa como um todo para dar alguma contribuição de fato. AGRADECIMENTOS

Os autores agradecem ao Laboratório de Computação Científica e Visualização – LCCV pela disponibilização de infra-estrutura requerida ao desenvolvimento deste trabalho. Ao mesmo tempo agradecem também ao CENPES/PETROBRAS pelo apoio na contratação do projeto que resultou neste trabalho. BIBLIOGRAFIA

Archer, G.C. et al., 1999. A new object-oriented finite element analysis program architecture. Computers & Structures 70 1, pp. 63–75.

Balevicius, R., Kacianauskas, R., Dziugys, A., Maknickas, A., Vislavicius, K., 2005.

DEMMAT code for numerical simulation of multi-particle systems dynamics, Information Technology and Control, Vol. 34, No. 1.

Bastian, M., Li, B. Q., 2003. An efficient automatic mesh generator for quadrilateral Finite

Elements in elements implemented using C++. Analysis and Design, vol. 39, pp. 905–930.

Cook, R.D., Malkus, D.S., Plesha, M. E., 1989. Concepts and Applications of Finite Element

Analysis, Third Edition, Jonh Wiley & Sons. Cundall, P. A. & Strack, O. D. L., 1979. A discrete numerical model for granular assemblies,

Geotechnique 29, No. 1, 47-65. Dubois-Pelerin, Y., 1992. Object-oriented finite element programming concepts and

implementation. PhD Thesis. Swiss Federal Inst of Tech, Lausanne. Ferreira, F. M. G., 2005. Desenvolvimento e Aplicações de um Framework Orientado a

Objetos para Análise Dinâmica de Linhas de Ancoragem e Risers (106 páginas), Dissertação (Mestrado), Programa de Pós-Graduação em Engenharia Civil, Universidade Federal de Alagoas.

Hulbert, G.M. & Chung, J., 1996. Explicit time integration algorithms for structural dynamics

with optimal numerical dissipation, Computer Methods Applied Mechanics Engineering, Vol. 137, pp. 175-188.

Lages, E. N., Paulino, G. H., Menezes, I. F. M., Silva, R. R., 1999. Nonlinear finite element

analysis using an object-oriented philosophy – Application to beam elements and to the Cosserat continuum. Engineering with Computer, vol. 15, pp. 73-89.

Levy, C. H.; Figueiredo, L. H.; Gattass, M.; Lucena, C.; and Cowan, D., 1996. IUP/LED: A

Portable User Interface Development Tool. Software: Practice & Experience, 737-762. Krysl, P., Belytschko, T., 1998. Object-oriented parallelization of explicit structural dynamics

with PVM, Computers & Structures, 66, 259-273. Martha, L. F., Menezes, I. F. M., Lages, E. N., Parente Jr., E., Pitangueira, R. L. S., 1996. An

OOP Class Organization for Materially Nonlinear Finite Element Analysis, XVII CILAMCE, Pádova, Itália, pp. 229-232.

Pantalé, O., 2005. Parallelization of an object - oriented FEM dynamics code: influence of the

strategies on the Speedup. Advances in Engineering Software, vol. 36, pp. 361–373. Rumbaugh, J., Jacobson, I., Booch, G., 2000. UML:GuiadoUsuário. Rio de Janeiro: Campus,

ISBN8-535-20562-4. Ricarte, I. L. M., 1995. Programação orientada a objetos com C++. Notas de apoio a cursos

– FEEC/UNICAMP. Disponível em: http://www.dca.fee. unicamp.br/ ~ricarte/. Acesso em: 20 de dezembro de 2005.

Stroustrup, B., 1997. The C++ Programming Language, 3 ed., Addison-Wesley. Woo, Neider and Davis, 2003. OpenGL Programming Guide (The Red Book), Version 1.3,

Addison.