March 27, 2008

Linguagem de Programação no OpenFOAM III

Este post é o último de uma seqüência que mostra conceitos e detalhes da linguagem de programação no OpenFOAM. Agora, por fim, vamos analisar uma biblioteca (header) usada em todos os códigos dos solvers do OpenFOAM, o fvCFD.H. Na declaração (ou uso) deste último, várias outras bibliotecas são definidas e fornecem acesso a vários comandos, operadores, funções, etc. implementados nas classes e templates do OpenFOAM. Vamos ao post!

Estruturas das bibliotecas no OpenFOAM
Como já foi mencionado, com base na programação orientada a objetos, as classes e templates podem encapsular tipos e operações sobre variáveis. Os arquivos que contém as classes são chamados de bibliotecas (ou headers) com extensão *.H. As classes devem ser declaradas no início do código para que seja possível usar e acessar os comandos presentes na mesma. A principal biblioteca do OpenFOAM é a fvCFD.H, usada para acessar várias outras bibliotecas importantes para o funcionamento do código. Sendo assim, qualquer solver do OpenFOAM possui esta biblioteca declarada no início de seu código. A estrutura básica desta biblioteca está representada na figura abaixo, indicando a declaração de algumas das principais bibliotecas do pacote CFD.
A biblioteca fvMesh.H é responsável por alocar os dados necessários para a discretização do domínio por volumes finitos, incluindo informações topológicas e geométricas da malha. Além disso, fvMesh.H (classe fvMesh) mantém esses dados atualizados durante a simulação, tendo liberdade para apagar informações sobre as células (volume, área da faces, posição do centro da célula/face, etc.) e recalculá-las quando for necessário. Assim, com esta biblioteca é possível apagar ou modificar dados referentes a mudanças topológicas (refinamento de malha) ou geométricas (malhas poliédricas móveis).

O OpenFOAM usa o método dos volumes finitos para discretizar os campos geométricos nas equações simuladas e as bibliotecas fvm.H e fvc.H são responsáveis pelo processo de aproximação dos termos derivativos das variáveis tensoriais calculadas. Apesar destas bibliotecas possuírem o mesmo propósito, suas aplicações são diferentes. A biblioteca fvm.H reúne funções para realizar operações implícitas de discretização pelo método dos volumes finitos e os resultados são armazenados em uma matriz definida pela classe fvMatrix. Em outras palavras, a classe fvm discretiza os termos das equações que irão ser resolvidos na simulação e constrói um sistema de equações lineares. A biblioteca fvm.H ainda é capaz de montar a matriz utilizando termos fontes com discretização implícita ou explícita. A formulação obtida pela classe fvm está descrita na equação mostrada abaixo, para uma variável φ genérica na célula k da malha, com vizinhos i.
Já a biblioteca fvc.H agrupa funções para calcular operações explícitas de discretização dos termos presentes nas equações. Os termos discretizados por essa classe não são armazenados em uma matriz, como na biblioteca fvm.H. Neste caso, as operações realizadas com a classe fvc retornam explicitamente um campo geométrico (classe geometricField). Por exemplo, essa biblioteca é particularmente útil na solução da equação mostrada acima, já que o OpenFOAM não inclui a pressão na matriz fvMatrix, já que utiliza um método segregado de solução para o acoplamento pressão-velocidade. Além das operações de discretização, essa biblioteca possui classes para integração de um campo tensorial sobre um volume ou superfície. As opções colocadas no arquivo de configuração da simulação fvSchemes selecionam em tempo de execução as classes responsáveis pela discretização das equações.

A biblioteca linear.H possui uma classe específica para interpolação com diferenciação central dos campos alocados no centro da célula para sua superfície.

Para resolver o sistema linear proveniente da equação discretizada utiliza-se a biblioteca fvMatrices.H. Esta última possui ferramentas para montar a matriz e o solucionador de sistemas de equações lineares especificamente projetados para soluções por volumes finitos de equações escalares. O endereçamento das variáveis nas faces dos volumes é usado para montar a estrutura da matriz e a vetorização dos laços de solução. O arquivo de configuração fvSolution seleciona em tempo de execução as classes usadas para solução dos sistemas lineares.

A definição das classes (fixedValueFvPatchField e calculatedFvPatchFields) que implementam a estrutura de dados e aplicam as condições de contorno na simulação são acessadas com a declaração das bibliotecas fixedValueFvPatchFields.H e calculatedFvPatchFields.H. As classes fixedValueFvPatchField e calculatedFvPatchFields retornam os coeficientes da matriz afetados pela condição de contorno (diagonal da matriz e termo fonte) para determinado patch. Ambas classes são derivadas de fvPatchField.H, uma classe abstrata (fvPatchField<Type>) que fornece uma interface que cobre todas as possíveis classes derivadas aplicadas ao contorno. A classe fvPatchField<Type> divide-se em dois níveis de classes derivadas, onde o primeiro nível é responsável pelas condições de gradiente nulo, gradiente fixo, campo com valor fixo e condições mistas no contorno. O segundo nível cobre todas as condições de contorno especializadas com procedimentos de cálculo específicos, particulares a determinadas situações e campos.

Ainda existem outras bibliotecas definidas em fvCFD.H, porém, apesar de serem importantes, eu as considerei como auxiliares. Entre estas, pode-se citar as bibliotecas parRun.H que testa e avalia os argumentos de uma simulação em paralelo; Time.H, que monta um banco de dados para controle de tempo (instante inicial, final, passo de tempo, etc.) da simulação e define operadores de incremento de tempo; physicalConstants.H que define os valores de variáveis constantes; Ospecific.H que contém funções específicas para operações no SO Unix; e argList.H para criação, escrita e checagem da lista de argumentos (argc e argv) que são passados para o programa executável.

Em muitos casos, os arquivos *.H declarados ao longo dos códigos de solvers do OpenFOAM têm apenas a função de executar comandos e definir variáveis. Apesar dessa prática fugir da definição básica de uma biblioteca, eu chamei todos os arquivos *.H como bibliotecas (ou headers).

Para entender melhor tudo o que eu escrevi aqui, é necessário estudar mais a fundo os códigos dos solvers do OpenFOAM (e C++ também, né?). É por isso que no futuro vou mostrar um estudo de caso. A avaliação de um dos códigos mais simples implementados no OpenFOAM: o laplacianFoam (usado na solução da equação de Laplace transiente). A partir dele, é possível entender melhor o funcionamento deste pacote CFD e seus códigos.

March 21, 2008

Feliz Páscoa!



Antes que eu me esqueça, a equipe do Notas em CFD deseja a todos uma Feliz Páscoa! Tomara que neste feriado seja finalmente possível descansar um pouco a cabeça. E depois a gente volta...

March 20, 2008

Começando a programar em C++

Resposta às dúvidas mais frequentes.

1. Quero me converter para o lado poderoso da força, mas essa história de C e C++ me confunde. O que é o quê?
A linguagem C foi criada no início dos anos 70 para ser usada na programação do UNIX. Cansados de fazer tudo em Assembly, os programadores resolveram criar uma linguagem que fosse estruturada e que permitisse programação low-level ao mesmo tempo. Assim nasceu a linguagem C.
/*
Isso está em C
*/

#include <
stdio.h>
#include <
string.h>

int main()
{
int a = 15;
int b = 20;
char buffer[128]; /* uma string é um array (ou vetor)
de bytes terminado por ASCII zero */

strcpy(buffer, "A variável [a] é ");

if(a > b)
strcat(buffer, "maior");
else
strcat(buffer, "igual ou menor ");

strcat(buffer, " que a variável [b]\r\n");

printf(buffer);

return 0;
}
O C++ é uma evolução da linguagem C, e foi criada por Bjarne Stroustrup. Nessa evolução foi adicionado à linguagem C o conceito de orientação à objetos, que virou moda naquela época (começo dos anos 80) e é muito usado hoje em dia. Além disso, o próprio C++ foi evoluindo no decorrer da década de 80 e 90, com a adição de recursos como templates e a STL (que veremos depois). O C++ tem tudo que a linguagem C tem (99,8% de compatibilidade) e mais toda a evolução. Todo compilador C++ que eu conheço compila código C sem problemas.
//
// Isso está em C++
//

#include <
iostream>
#include <
string>

using namespace std;

int main()
{
int a = 15;
int b = 20;
string buffer; // string é um objeto

buffer = "A variável [a] é ";

if(a > b)
buffer += "maior";
else
buffer += "igual ou menor ";

buffer += " que a variável [b]";

cout << style="color: rgb(0, 0, 153);">return
0;
}
O exemplo feito em C, é compilado sem problemas por qualquer compilador C++, já que ele é também um código C++ válido.

2. Preciso aprender C antes de aprender C++?
Não, não e não. Eu recomendo que você aprenda C++ direto, sem passar pelo C, já que hoje em dia o C++ é mais usado. Se algum dia você precisar fazer algo em C, é só estudar as limitações do C em relação ao C++. As estruturas básicas de controle (if, while, switch...) são as mesmas, o que muda é que a linguagem C não suporta todos os recursos do C++, com suporte à programação orientada a objetos, bibliotecas, templates, etc. Mesmo assim, em C++ você pode usar as bibliotecas do C sem problemas.

3. Todo mundo diz que C++ é muito complicado. Isso é verdade?

Você é um homem ou um rato? C++ requer mais estudo por ser uma linguagem completa e poderosa, mas não é nada que um ser humano normal não consiga aprender. Tem gente que acha que usar o Microsoft Word é complicado. Esqueça o que os outros dizem e estude aquilo que você tem vontade.

4. A moda agora é .NET e Java, será que vale a pena estudar C++?
Vale. Como as pessoas estão indo para as linguagens mais fáceis, os profissionais de C++ são mais valorizados. Afinal, quando se precisa de algo 10 vezes mais rápido, alguém precisa fazer. Não se esqueça que praticamente todos os softwares comerciais que existem são feitos em C ou C++ (Windows, Office, SQL Server, Oracle, Photoshop, CorelDRAW, Linux, Visual Studio, o próprio .NET e todas as VMs Java, etc, etc, etc).

5. Eu já ouvi falar que o Java e o C# são versões melhoradas do C++. Isso é verdade?
Se você acha que uma versão mais limitada de alguma coisa é uma melhoria... O Java e o C# são baseadas na linguagem C++, tirando muitos recursos que, apesar de poderosos, causavam confusão ou dificuldade. Foi feita uma simplificação e um nivelamento por baixo (ok, pelo meio) para atender às necessidades mais comuns. Por serem mais simples, essas duas linguagens são indicadas para aplicativos tecnicamente mais simples, como os que manipulam bancos de dados, controlam regras de negócios e fazem entradas de dados. As duas runtimes (JVM e .NET) têm algumas vantagens sobre o C++, como gerenciamento automático de memória, independência relativa de arquitetura e mais facilidade para leitura dos metadados (enumerar as classes de um DLL, por exemplo). Mas têm a desvantagem de consumirem bem mais memória, serem mais lentas (isso pode melhorar com o tempo) e terem limitações técnicas que as impedem de desenvolver certos tipos de software (como device drivers).

6. Onde posso achar mais informações sobre C++?
Wikipedia - Linguagem C
Wikipedia - C++
Bjarne Stroustrup's C++ FAQ
Bjarne Stroustrup's C++ Style and Technique FAQ
Google: "C++ tutorial" (antes que alguém pergunte...)

7. Ok, Ok... Mas o que isso tem a ver com CFD?
Você tem lido os outros posts desse blog?

Esse artigo é uma adaptação do original publicado no 1Bit, escrito por Rodrigo Strauss.

March 15, 2008

O mundo em 64 bits

A maior vantagem dos processadores de 64 bits em relação aos seu primos de 32 bits é o suporte para grande quantidade de memória. Na teoria, um processador de 64 bits pode alocar exabytes (bilhões de bilhões de bytes) de memória RAM, enquanto os chips com 32 bits podem alocar no máximo 8 GB de RAM (usando componentes de hardware especiais - nunca vi ninguém com sistema 32 bits com mais de 2 GB de RAM). Além disso, as aplicações de 64 bits podem realizar operações de ponto flutuante (operações matemáticas envolvendo números reais) mais rápido que as aplicações específicas para 32 bits. Também necessária para renderização 3D e animações, as operações em ponto flutuante são tão importantes para a análises científicas que os FLOPS (floating-point operations per second) são usados para medir a performance de supercomputadores. A habilidade dos chips de 64 bits em processar operações de ponto flutuante mais rápida e com maior precisão (quase o dobro de casas decimais) que seus parentes de 32 bits os torna poderosas ferramentas para simulação e visualização de dados.

Hoje, a maioria dos computadores desktop não possuem nem 4GB de memória instalada e, além disso, a maioria dos programas usuais de escritório e para casa não requer tanta memória assim. Conforme os programas forem ficando mais complexos e os jogos com maior detalhamento 3D, pode ser que isto se torne uma limitação. Mas na minha opinião, o usuário doméstico vai poder usar o seu PC 32 bits durante um bom tempo sem maiores preocupações.

De fato, os maiores benefícios que os computadores de 64 bits fornecem vão passar despercebidos se o sistema operacional, seus drivers e programas não forem adaptados a essa arquitetura. Ao migrar de um sistema 32 para 64 bits, o usuário não irá notar diferença de velocidade nos seus programas de internet ou processador de texto. Os benefícios serão vistos ao usar aplicações que demandam mais poder do processador, como codificação de vídeos, pesquisa científica (simulações CFD, por exemplo) e pesquisa em banco de dados (massive data mining).

Minha experiência em 64 bits
Recentemente, meu orientador comprou máquinas novas para o Laboratório e eu fiquei com um presentão (devo ter sido um bom menino e trabalhado na minha tese direitinho ou ele está querendo é que eu trabalhe mais ainda!!). Um Core 2 Quad 6600 2.4GHz, com 8 GB de RAM. Para quem não sabe, ele possui um núcleo quadri-processado (4 processadores independentes). Sem dúvida pensei logo em instalar um sistema 64 bits para poder usar toda a memória RAM instalada no micro. Como trabalho com o OpenFOAM e o pessoal que desenvolve o dito usa o Linux OpenSUSE, resolvi instalá-lo no micro. No início foi um pouco estranho (estava acostumado com o Ubuntu e o Fedora), mas agora está tudo indo muito bem. Hoje sou um feliz usuário de um Linux SUSE 64 bits.

Não tive nenhum problema com compatibilidade de hardware com o sistema operacional 64 bits ou seus dirvers. Tudo foi reconhecido perfeitamente (como qualquer distribuição Linux que se preze faria). Além disso, existe uma infinidade de programas já prontinhos para a arquitetura 64 bits disponíveis para download nos repositórios do OpenSUSE (todos gratuitos, diga-se de passagem). Contudo, além de ser um processo bem mais demorado que no Ubuntu (leva mais ou menos 1 minuto para carregar o gerenciador de programas - Yast2), existem alguns programas que eu usava em Linux 32 bits que ainda não foram compilados para 64 bits (ou não estão no repositório do SUSE). Mas isso não foi problema algum, pois baixei o código-fonte deles e estão funcionando perfeitamente. Porém existem programas que eu definitivamente não consegui fazer funcionar no SUSE 64 bits, por exemplo o Google Earth.

Mas o que me chamou a atenção foi outro detalhe. Um dia eu estava usando o computador normalmente (internet, editor de texto simples e o Kile - editor para Latex) e percebi que o computador tinha alocado quase 1 GB de memória RAM para estes programas. Putz!! Como assim? Quando eu usava um sistema 32 bits, normalmente era alocado no máximo uns 500 Mb de RAM ao usar estes mesmos programas. Bem, esse é um fato. O sistema 64 bits aloca os dados na memória com maior precisão, então deve precisar de mais espaço para alocar tudo! Por isso ele estava alocando mais memória do que o sistema 32 bits. Hum... O sistema te fornece mais recursos, mas também exige mais memória. Troca justa, o preço da memória RAM baixou muito!

Vamos ao que interessa... Simulações CFD! O que mais impressiona é a quantidade de memória que pode ser alocada. Em outras palavras, isso significa usar uma malha maior. De fato, antes era impossível construir malhas com um número de na casa do milhão em computadores 32 bits pela limitação da memória. Com mais memória, a malha pode ser mais refinada, produzindo resultados com maior detalhamento. Além disso, tendo o driver de vídeo bem configurado, a visualização dos resultados está ótima. O paralelismo nada tem a ver com o sistema ser 64 ou 32 bits, mas vou dizer uma coisa: é ótimo!

Instalei o ANSYS CFX 11 e o OpenFOAM sem problemas. Realmente, o SUSE é mais propício para a compilação do código fonte do OpenFOAM. Seguindo os passos do Wiki do OpenFOAM, não tive muitos problemas (algumas coisinhas relacionadas com o ParaFoam) em compilar o dito. O único problema mesmo é com o workbench do CFX. Não tem jeito de fazer esse treco funcionar no Linux (algum milagre, talvez?). A versão de Linux recomendada para usar o workbench já está tão ultrapassada que talvez seja aquela que eu preciso reconfigurar tudo para trocar o monitor. Isso eu não vou usar. É impraticável!

Por fim, essas são as minhas impressões sobre 64 bits e o sistema Linux que eu instalei. O Mitre também já comentou sobre as impressões sobre o mundo em 64 bits. Veja aqui o relato dele.

March 13, 2008

Linguagem de Programação no OpenFOAM II

Neste post, vamos ver como os conceitos de orientação a objetos ajudam na interpretação de propriedades físicas pelo OpenFOAM.

Interpretação da Linguagem pelo OpenFOAM
A vantagem do uso da linguagem matemática é a eficiência em expressar conceitos abstratos. Por exemplo, no escoamento de um fluido, o termo "campo de velocidade" possui um significado mesmo sem qualquer menção à natureza do escoamento ou qualquer dado específico de velocidade. O termo encapsula a idéia de movimento com direção e magnitude e a relação com outras propriedades físicas. Na matemática, pode-se representar o campo de velocidades por um único símbolo, por exemplo, u, e expressar certos conceitos usando símbolos, por exemplo, o campo de magnitude de velocidade como |u|. Assim, se torna possível expressar conceitos complexos com extrema clareza.

As equações da mecânica do contínuo são usualmente apresentadas como equações diferenciais parciais em 3 dimensões no espaço e com variação no tempo. Estas equações contêm conceitos de escalares, vetores, tensores e seus respectivos campos, e envolvem álgebra tensorial, cálculo tensorial e sistemas de unidades. A solução destas equações envolve procedimentos de discretização, representação de matrizes e implementação de algoritmos de solução de sistemas de equações lineares. A técnica de orientação a objetos usada pelo OpenFOAM permitiu criar tipos de dados muito próximos aos usados na mecânica do contínuo, e a técnica de sobrecarregamento de operadores permitiu que a simbologia matemática usual fosse aplicada para operações básicas.

As classes implementadas no OpenFOAM declaram tipos e operações associadas que fazem parte da linguagem matemática utilizada na engenharia e no meio científico. O campo de velocidades apresentado anteriormente pode ser representado no código de programação pelo símbolo U e a magnitude do campo de velocidade pode ser mag(U). A velocidade é um campo vetorial e, portanto, deve existir, em um código com orientação a objetos, uma classe vectorField. Então, o campo de velocidade pode ser visto como um objeto da classe vectorField.

A clareza no uso de objetos na programação para representar objetos físicos e entidades abstratas não deve ser subestimada. A estrutura das classes restringe o desenvolvimento do código dentro das próprias classes, tornando o código mais fácil de manipular. Novas classes podem herdar propriedades de outras classes, por exemplo, um vectorField pode ser derivado de uma classe vector e uma classe Field. C++ fornece um mecanismo chamado de classes template, de forma que a classe Field pode representar um campo qualquer, como scalar, vector e tensor. As características gerais da classe template são passadas para qualquer classe criada a partir deste template. Os templates e a herança reduzem a duplicação de código e criam hierarquias de classe que impõe uma estrutura ao código.

Assim, utilizando as classes do OpenFOAM, a sintaxe de escrita dos solvers se assemelha à solução de equações diferenciais parciais. Por exemplo, veja a equação abaixoé representada pelo código em C++
solve
(
fvm::ddt(rho,U)
+ fvm::div(phi,U)
- fvm::laplacian(mu,U)
==
- fvc::grad(p)
);
Os códigos dos solvers são seqüenciais já que representam um algoritmo de solução e suas equações, que são seqüenciais por natureza. Os usuários não necessitam de um grande conhecimento de programação orientada a objetos e C++ para escrever um solver, mas devem conhecer os princípios por trás da orientação a objetos e ter um conhecimento básico da sintaxe de C++.

O conhecimento das equações, modelos, métodos de discretização, solução e algoritmos é definitivamente muito mais importante. Com esse ponto de vista, recomendo fortemente que o leitor interessado em estudar a fundo o OpenFOAM leia o trabalho de tese do Jasak (1996) [1]. O trabalho explica em detalhes vários aspectos sobre a formulação numérica (discretização por volumes finitos, funções de interpolação, condições de contorno, etc.) e a teoria dos algoritmos implementados (acoplamento pressão-velocidade, correção dos fluxos em malhas não estruturadas, etc.) no OpenFOAM. Toda a implementação do código é baseada na teoria apresentada nesta tese. Existem mais duas fontes na literatura, Jasak et al. (2004) [2] e Weller et al. (1998) [3] contendo detalhes sobre o código e aplicações práticas do OpenFOAM.

Se estão começando a estudar CFD (métodos numéricos e algoritmos) e querem usar o OpenFOAM, leiam os trabalhos citados aqui (os links para download estão logo abaixo). Mas nada impede que vocês já comecem a usar o OpenFOAM.

Referências Bibliográficas:
[1] Jasak, H., 1996. Error analysis and estimation for the Finite volume method with applications to Fluid Flows. Tese de Doutorado, Imperial College of Science, Technology and Medicine, UK.
[2] Jasak, H., Weller, H. G., Nordin, N., 2004. In-cylinder CFD simulation using a C++ object-oriented toolkit. Paper number 2004-01-0110. SAE World Congress, Detroit.
[3] Weller, H. G., Tabor, G., Jasak, H., Fureby, C., 1998. "A tensorial approach to continuum mechanics using object-oriented techniques". Computers in Physics 12 (6), 620 - 631.

March 11, 2008

OpenFOAM e 64 bits

Este post responde a um comentário muito relevante do Délio sobre a instalação do OpenFOAM em sistemas 64 bits, os arquivos .bashrc no Linux e o uso do foamInstallationTest. Veja a pergunta do Délio no post da instalação do OpenFOAM e a sua resposta está colocada abaixo.
Olá Délio,

Agradeço muito pelo seu comentário. O objetivo desse blog é aumentar mesmo a interação entre os usuários de CFD. Bem, como você é novo no Linux, vou comentar antes sobre o arquivo .bashrc.

O arquivo .bashrc que está no seu diretório HOME é lido toda a vez que você entra no Linux. E relido sempre que você entra no terminal. Então veja a sequência de fatos... Você entra no terminal e a linha de configuração do OpenFOAM,

. $HOME/OpenFOAM/OpenFOAM-1.4.1/.OpenFOAM-1.4.1/bashrc

é lida e executa o arquivo bashrc do OpenFOAM. Esse arquivo fornece ao sistema todas as configurações necessárias para executar o OpenFOAM. Beleza! Só que esse arquivo não diz se o sistema é 32 ou 64 bits.... (Na minha opinião, isso é meio que um furo da OpenCFD, mas...). Vamos acertar isso, então. Antes de executar a linha de configuração do OpenFOAM, vamos dizer ao sistema qual a arquitetura do dito. Então, faça assim no arquivo .bashrc do seu HOME.

WM_64=on
. $HOME/OpenFOAM/OpenFOAM-1.4.1/.OpenFOAM-1.4.1/bashrc

Agora, a variável de 64 bits já vai estar ativada antes do OpenFOAM fornecer as configurações ao sistema, e, portanto, os caminhos (para 64 bits) vão estar corretos agora. Não é preciso reinstalar nada, só faça isso. Feche o terminal e abra de novo.

Em relação ao foamInstallationTest... Esqueça esse cara. Ele era muito útil na versão 1.0 do OpenFOAM, mas depois ficou defasado. Muitas informações dali estão furadas (pelo menos para os usuários simples - se a sua intenção é montar um cluster de computadores a coisa muda de figura). Verifique se tudo está OK apenas executando o icoFoam e depois o paraFoam.

Mais uma vez agradeço ao comentário do Délio e dizer que isso promove a interação entre os leitores do blog (e enche os autores de satisfação).

De fato, já tenho (quase) pronto um post sobre as diferenças do mundo 32 e 64 bits e minha experiência com a arquitetura de 64 bits. Esperem pra ver!

No limite da Fluidodinâmica

Em trabalhos recentes existe grande interesse em explorar as interações entre líquidos e superfícies. Estes estudos possuem aplicações que vão da produção de superfícies altamente repelentes a água a tecidos anti-mofo e muito mais. O completo entendimento sobre o que acontece em uma superfície e como isso influencia as propriedades no seio do líquido é uma tarefa desafiadora devido aos limites de escala envolvidos no processo. Veja a cavitação como exemplo: quando as hélices de um navio giram suficientemente rápido, a pressão ao longo do caminho das hélices cai substancialmente permitindo que o gás dissolvido na água forme bolhas. Estas bolhas reduzem a eficiência da hélice, geram muito barulho (muito ruim se o objetivo é se manter quieto) e causa erosão na hélice. As bolhas normalmente se formam em uma escala nanométrica e crescem rapidamente a escalas micro ou milimétricas antes de colapsarem conforme a pressão volta ao normal.

Assim, para entender a cavitação deve-se lidar com fenômenos que ocorrem entre as escalas nano e milimétricas (uma diferença de 6 ordens de magnitude!). Computacionalmente, isso significa usar um tamanho de malha que possua detalhamento para capturar efeitos em escala nano assim como ter espaço suficiente para incluir as bolhas de tamanho milimétrico. Experimentalmente, as técnicas existentes para visualizar escalas muito pequenas são de captura muito lenta e não funcionam muito bem em áreas muito grandes. Um trabalho recente [1] tentou avaliar ambas escalas simultaneamente e, ao fazer isso, mostrou como nossa percepção sobre as relações entre objetos em escalas nano e objetos macroscópicos falha miseravelmente.

Um fenômeno estranho que vêm sendo observado nos últimos anos são as nano-bolhas de superfície. Esses "carinhas" são bolhas de gás, com raios em torno de 100 nm, localizadas entre a interface de um líquido e um sólido. De acordo com a mecânica dos fluidos clássica, estas bolhas deveriam ser instáveis pois seu pequeno raio de curvatura induz uma forte pressão ao longo de sua superfície, o que deveria quebrar a bolha em mil pedacinhos. A Mãe Natureza, mostrando seu senso de humor, permite que esses "carinhas" sobrevivam por horas a fio.

Os pesquisadorem teóricos usaram a presença e a persistência das nano-bolhas para fornecer possíveis mecanismos para, entre outras coisas, o escorregamento de fluidos em superfícies e o início da cavitação em uma superfície. Pesquisadores na Holanda começaram a explorar a relação entre a cavitação e as nano-bolhas de superfície. Eles escolheram condições de líquido-superfície que permitem o controle da densidade das nano-bolhas e usaram esta superfície para gerar bolhas de cavitação. Usando um microscópio atômico e uma câmera, eles foram capazes de mostrar que as nano-bolhas persistem mesmo se a pressão cai a 6 MPa conforme uma onda de choque passa pelas ditas. Além disso, eles mostraram que não existe uma relação óbvia entre a cavitação e as nano-bolhas.

Agora a situação é bem estranha... Nós temos bolhas que persitem em existir mas não deviam existir. Pior ainda, as bolhas não expandem quando a pressão cai e elas, aparentemente, não formam bolhas maiores. E o que podemos tirar disso tudo?
  • Primeiro, o método usado para medir as nano-bolhas é muito lento comparado à evolução da onda de choque. Dessa forma, não se tem a menor idéia do que acontece com a bolha quando a onda de choque passa por ela (isso indica que é necessário desenvolver técnicas de captação de imagem mais rápidas para escalas nano). Contudo, o fato das bolhas existirem antes e depois da onda de choque indica que estas não participam da cavitação.
  • Segundo, um raio de 100 nm fornece uma área superficial de aproximadamente 20 milhões de moléculas de água, o que não é um número muito grande. Eu me perguntaria até onde a fluidodinâmica, com sua hipótese do contínuo, pode ser aplicada sobre estas circustâncias. Na superfície das bolhas, essa pergunta já foi respondida, uma vez que o surgimento destas bolhas não conseguiu ser explicado usando a abordagem de mecânica dos fluidos clássica.
Contudo, é provável que as abordagens usadas até agora não fizeram uso das equações completas de Navier-Stokes, mas uma aproximação destas. Mas mesmo assim, é uma pergunta interessante: quão pequena deve ser a escala de um fluido até que este não seja mais um fluido?

Revisão Bibliográfica:
[1] B. M. Borkent, S. M. Dammer, H. Schönherr, G. J. Vancso e D. Lohse, Superstability of Surface Nanobubbles, Physical Review Letters, 98, 204502 (2007)

Adaptado de um artigo do Ars Technica. Quer saber mais sobre as nano-bolhas? Veja aqui, aqui e aqui.

March 8, 2008

Linguagem de Programação no OpenFOAM I

Uma das dificuldades inerentes aos novos desenvolvedores são referentes aos conceitos e a sintaxe básica de programação no OpenFOAM, sejam eles leigos em programação ou não. Uma boa fonte para o leitor interessado é estudar C++ pelos livros do Deitel (as edições anteriores possuem versão em português) e do Yang (ótimos exemplos aplicados a métodos numéricos). Gosto muito desse último.

Atualmente, as únicas fontes sobre programação no OpenFOAM estão em seus manuais (User's Guide e Programmer's Guide). Porém, ao meu ver, estes não são suficientes para que o usuário iniciante seja capaz de escrever seu próprio solver, sendo necessário um certo esforço para estudar os códigos existentes, a estrutura e o funcionamento dos algoritmos implementados.

Em uma seqüência de 3 posts, vou tentar passar os conceitos básicos sobre orientação a objetos (com ênfase e aplicações em C++) e a minha experiência no aprendizado da linguagem do OpenFOAM, evitando entrar em detalhes sobre sintaxe do código neste primeiro momento (mas vou chegar lá... esperem só pra ver!). Neste primeiro post, vamos ver o que C++ pode nos oferecer para a programação de um código científico.

Orientação a Objetos e C++
A maior vantagem na abordagem aplicada à orientação a objetos é remover algumas das falhas encontradas na abordagem seqüencial ou contínua. Na abordagem orientada a objetos, os dados são tratados como elementos críticos do programa e não é permitido alterá-los livremente. Os dados são associados a funções que os acessam e operam, protegendo-os de modificações por uso de funções externas. A orientação a objetos permite a decomposição do problema em entidades chamadas objetos, com a construção de dados e funções para operar sobre esses objetos. Uma grande vantagem na abordagem de orientação a objetos é a reusabilidade do código.
Para melhor entendimento da linguagem orientada a objetos, os conceitos de objetos, classes, abstração de dados e encapsulamento, herança e polimorfismo estão colocados na seqüência.
Objetos são as entidades básicas de um sistema orientado a objeto. A programação é analisada em termos de objetos e na forma de comunicação entre eles. Quando um programa é executado, os objetos interagem uns com os outros por envio de mensagens, mesmo sem que estes tenham conhecimento sobre detalhes dos dados ou código. As classes formam uma coleção de objetos similares entre si.

A abstração se refere ao ato de representar aspectos essenciais do programa sem incluir detalhes ou explicações básicas de programação. Classes usam o conceito de abstração e são definidas como uma lista de atributos abstratos. O armazenamento de dados e funções em uma única unidade (classe) é chamado encapsulamento. Com isso, os dados não podem ser acessados diretamente e somente as funções encapsuladas na classe podem acessá-los.

Herança é o processo no qual os objetos podem adquirir as propriedades de objetos de outras classes. Esta característica proporciona a reusabilidade do código, como adicionar novas propriedades a uma classe existente sem modificá-la. Para tal, deriva-se uma nova classe a partir de uma já existente. A nova classe terá aspectos combinados das duas classes.

Por fim, o polimorfismo caracteriza a habilidade de realizar operações com diferentes comportamentos em situações diversas. O comportamento da operação depende do tipo de dado usado na operação. O polimorfismo é usado extensivamente na implementação da herança do código.

Tendo sido colocado essas informações, pode-se descrever algumas vantagens da programação orientada a objetos em relação às abordagens convencionais, como:
  • Fornecer uma estrutura modular para programas, facilitando a definição de tipos de dados abstratos onde detalhes da implementação estão escondidos e a unidade possui uma interface claramente definida.
  • Tornar mais fácil a manutenção e a modificação de códigos, assim como novos objetos podem ser criados com pequenas diferenças entre os existentes.
  • Fornecer uma boa estrutura para bibliotecas de códigos onde os componentes de um software podem ser facilmente adaptados e modificados pelo programador.
Para entender como é o funcionamento das bibliotecas do OpenFOAM, é necessário ter um conhecimento prévio de C++, a linguagem base do OpenFOAM. Esta é uma linguagem orientada a objetos e, portanto possui todas as características descritas acima. Por ser baseada na linguagem precursora C, C++ é uma linguagem de programação apropriada para trabalho científico, devido à rapidez com que os cálculos são efetuados. Contudo, as propriedades inerentes à orientação a objetos em C++ propiciam uma perda de cerca de 10% na velocidade de processamento em relação à linguagem C. Esta perda na eficiência pode variar dependendo da conscientização do programador em relação à efetividade computacional. Estudos [1] foram realizados avaliando a aplicabilidade de códigos escritos em C++ na construção de algoritmos eficazes em cálculos de problemas CFD, aplicando algoritmos que reduzem o tráfego de dados e balanceando o polimorfismo do código com a eficiência computacional.

Por fim...
Se você realmente está interessado em desenvolver programas CFD usando o OpenFOAM, entenda os conceitos de C++ antes de mais nada. Leia este post com carinho, clicando nos links com as definições (que eu tive a paciência de procurar para você!!) e entendendo o que cada uma delas significa. Em seguida, parta para o estudo básico da linguagem chegando ao avançado (usando um livro como base, apostilas, internet, grupos de discussão...).

Até a próxima!

Referências Bibliográficas:
[1] Malan, A. G., Lewis, R. W., 2004. On the development of high-performance C++ object-oriented code with application to an explicit edge-based fluid dynamics scheme. Computers & Fluids 33 (10), 1291.

Ps.: Atualmente, estou treinando 4 alunos de graduação em OpenFOAM. Nenhum deles tinha experiência em programação e a intenção é que eles trabalhem em desenvolvimento de códigos CFD. Eu comecei o treinamento deles com o estudo do livro do Yang, fazendo os exercícios que eu tinha selecionado (se quiserem, depois posso postar quais foram). Mas um detalhe! Eles não podiam mexer no OpenFOAM até chegarem ao Cap. 5 do livro, onde os conceitos de orientação a objetos eram introduzidos. A partir desse ponto, os alunos começaram o treinamento em OpenFOAM lendo o User's Guide e executando os tutoriais e, em paralelo, continuavam o estudo de C++. "Mas por que fazer assim, Luiz F.?", você deve se perguntar...
Nessa etapa, o básico de programação (iteração, laço, condicionais, entrada e saída de arquivos, etc...) já foi aprendido e os alunos estão prontos para aprender os conceitos de orientação a objetos (e C++ avançado). Apesar de estar nas entrelinhas, estes conceitos estão entranhados no User's e Programmer's Guide do OpenFOAM. Assim, os alunos irão aprender a linguagem avançada de C++ e sua aplicação na estrutura do OpenFOAM concomitantemente. Pode até ser que os alunos não se dêem conta disso no primeiro momento, mas quando eles acabarem o estudo do Yang (classes, templates, etc) e de ler os dois guias do OpenFOAM vão ter uma visão muito mais completa do código CFD.

Além disso, não mexer em CFD até chegar ao Cap. 5 de um livro?? Putz... Eles querem chegar logo ao OpenFOAM!! Estudam o livro e fazem os exercícios rapidinho!!

E aí, o que você acha disso? Comente!

March 4, 2008

CFD em Esportes - Quebra de recordes

Complementando um post anterior. Uma rapidinha...

Novamente, simulações CFD foram usadas para analisar as causas do arrasto na pele e, assim, projetar uma roupa especial com o intuito de reduzi-lo. Outro ponto interessante é que as simulações também são usadas no treinamento dos atletas, mostrando até os efeitos causados pela posição dos dedos na performance do nado.

Recentemente, saiu o anúncio de mais um avanço na tecnologia de roupas de natação, a Speedo LZR Racer swimsuit. Na semana em que foi lançada, três recordes mundiais já foram quebrados. Esta nova roupa reduz a arrasto em 5% em relação a roupa projetada no ano passado (o que é um avanço significativo).

Bem, o preço dessa belezinha gira em torno de 320 libras (mais ou menos 1200 reais - sem contar os impostos de importação). Enquanto o preço não baixa, acho que vou continuar a quebrar os meus próprios recordes usando apenas minha touquinha de borracha de 15 reais.

Veja a notícia completa aqui.

Ps. Devia cobrar pela propaganda gratuita! Mas o pessoal do AQUALAB está fazendo um grande trabalho e isso já basta para mim.