Dados de contorno "híbridos" e "conservativos" no ANSYS CFD-Post.

Quando pós-processamos simulações do ANSYS CFX no ANSYS CFD-Post, em muitos painéis aparece o item "Boundary Data" com as opções "Hybrid" e "Conservative", com a opção híbrida sendo a padrão na maioria dos casos. Isso é visto na figura abaixo. Agora, o que são essas opções e de onde surgem? 

 Para entender essas opções é preciso conhecer um pouco melhor como o CFX trata a parede em simulações com modelagem de turbulência (ou seja, em praticamente todos os casos). Assim, para explicar essa ideia vou usar como exemplo a função de parede escalável do CFX (padrão quando se usa algum modelo de turbulência baseado na equação de épsilon).

A função de parede escalável, em termos gerais, define que a parede definida geometricamente não é a parede do domínio do fluido. O CFX considera que a parede do domínio fluido está deslocada um pouco "para fora" do domínio definido pela malha. Sem entrar em muitos detalhes sobre modelagem de parede, isto é feito para que, mesmo refinando muito a malha próximo à parede, o resultado utilizando lei de parede (logarítmica) seja o mais adequado possível. Dessa forma o CFX considera que o ponto sobre a parede está em y+=11,06, no limite de validade da lei de parede logarítmica.

Alguns podem ficar apreensivos sobre esse deslocamento de parede gerar erros na simulação. Não se preocupem com isso. Para o escoamento de água em um duto com 1m de diâmetro a 1m/s de velocidade (Reynolds aproximadamente 1,0e+06) esse "deslocamento virtual" da parede, para y+=11,06, é da ordem de apenas 1,0e-04m (um décimo de milímetro), muito provavelmente o próprio modelo de turbulência, alguma incerteza no valor da condição de contorno, etc., geram erros bem maiores do que esse.

Bom, agora fica simples entender o que são as opções híbrida e conservativa que aparecem no Post para simulações do CFX. A opção conservativa mostra a velocidade no domínio calculada pelo Solver, incluindo a solução para os nós na parede geométrica que, como não são considerados a parede do domínio fluido, tem velocidades diferentes de zero. Como se pode ver na figura abaixo (quem conhece esse caso?).

A opção híbrida mostra os resultados calculados pelo Solver no interior do domínio mesclada (daí o nome híbrido) com os valores de condição de contorno definidos no CFX-Pre. Como no CFX-Pre as paredes são definidas usando a condição de não deslizamento e, na maioria dos casos, termo paredes com velocidade nula, a condição de contorno de parede é com velocidade zero na parede. Então, misturando a solução do Solver para o domínio com as condições de contorno temos uma exibição com velocidade zero nas paredes, como mostrado na figura abaixo.

Assim, na hora de fazer o pós-processamento da simulação, estamos interessados no dado híbrido, que nos dá as condições esperadas da solução. Até porque vai mostrar para o chefe que não entende nada de simulação essa figura com velocidade diferente de zero na parede! Usualmente apenas quem está interessado nas questões numéricas vai queres visualizar os dados conservativos. Então, na grande maioria dos casos, híbrido neles!

Qualquer dúvida ou sugestão de post, por favor mandem nos comentários. 

Saudações.

Malhas estruturadas e não-estruturadas vs. malhas tetraédricas e hexaédricas

Um erro muito corriqueiro, mas muito mesmo, em artigos, apresentações, relatórios, etc., é se referir a malhas hexaédricas (ou quadriláteras) como "malhas estruturadas". Quando se trata de ANSYS FLUENT ou ANSYS CFX esse erro é ainda mais evidente. Já explico o porquê. Primeiro vamos ver a definição de malha estruturada e malha não estruturada. 

Para explicar o conceito, peguei duas figuras emprestadas do livro do prof. Maliska:

MALISKA, C. R. Transferência de Calor e Mecânica dos Fluidos Computacional. 2ª Edição. Rio de Janeiro: LTC Editora S.A., 2004. 472 p.

Imaginando que se deseja simular a transferência de calor, ou o escoamento ao redor de um tubo (por exemplo), pode-se utilizar qualquer uma das malhas abaixo:

A primeira malha é "usualmente" dita estruturada e a segunda é dita não estruturada. Quanto a segunda ser não estruturada, tudo bem, ela realmente é, mas isso é uma das características dela, é uma malha composta por volumes (ou elementos) triangulares não estruturada.

Quanto a primeira ser estruturada, daí depende. A única coisa que se pode dizer ao certo, apenas de olhar, é que é uma malha composta por volumes (ou elementos) quadriláteros, nada mais!

Para essa malha ser estruturada, a numeração dos volumes (ou elementos) deve seguir uma "estrutura fixa" de forma que o número de cada volume seja consecutivo ao seu vizinho. Um exemplo disso está na figura abaixo (analisando um quarto da primeira malha).

Como se pode observar, a primeira camada de volumes está numerada consecutivamente e assim por diante para as camadas (na direção radial) mais internas. Dessa forma todos os vizinhos de cada volume são conhecidos e obtidos de uma forma bem simples, uma conta algébrica trivial. 

Por exemplo, para o volume 17: o vizinho radial externo é 17-15=2; o vizinho de um lado é 17-1=16; do outro é 17+1=18 e; o vizinho radial interno é o 17+15=32. E isso vale para qualquer outro elemento da malha. O fato de "conhecer seus vizinhos" através de expressões simples traz um número enorme de vantagens na hora de programar um código. Facilita o cálculo dos balanços, diminui o número de acessos à memória, diminui a própria quantidade de memória necessária, e assim vai. A malha acima é dita então estruturada composta por elementos quadriláteros.

Agora, quem disse que essa malha é numerada assim? Ela pode ter sido gerada (por algum motivo qualquer, dependendo do software e do método utilizado na geração) assim:

Se os volumes estiverem numerados dessa forma, já era a malha estruturada. Claramente não há mais como conhecer os vizinhos de qualquer elemento da malha por simples conta algébrica. Dessa forma a "mesma" malha (com volumes e nós exatamente nas mesmas posições da anterior) deixa de ser estruturada. Agora é necessário se ter na memória, matrizes (ou vetores) de "conectividade". Essas matrizes são listas dizendo, para cada volume, quem são seus vizinhos. Isso é então uma malha não estruturada composta de elementos quadriláteros.

O uso da malha não estruturada faz com que o código a ser programado seja mais complexo. Também impõe que se tenha que acessar a matriz de conectividade várias vezes, aumentando o número de operações na máquina em relação à malha estruturada. Essas são algumas desvantagens. Além dessas, geralmente o uso de malhas não estruturadas gera vizinhos "muito distantes" (em termos da numeração deles, como o 5 que é vizinho do 92 acima), isso também prejudica questões de alocação de memória (principalmente).

A vantagem da malha não estruturada é que, em geometrias complexas, consegue-se gerar uma malha com relativa facilidade. Fazer uma malha estruturada não é tão simples e, em casos bastante complicados, chega a ser impossível.

Dessa forma fica evidente que uma malha composta por volumes quadriláteros (ou hexaédricos) não é necessariamente uma malha estruturada. Da mesma forma uma malha composta por elementos triangulares ou tetraédricos pode ser uma malha estruturada. Imagine simplesmente se dividir em 2 triângulos cada volume quadrilátero da malha estruturada acima, ainda assim poderemos saber quem são os vizinhos de cada volume através de expressões algébricas bastante simples. Assim teríamos uma malha estruturada composta por elementos triangulares.

No início do post eu falei que quando se trabalha com ANSYS FLUENT ou ANSYS CFX o "erro" de se chamar malhas hexaédricas de estruturadas é ainda mais evidente. Isso é porque nenhum dos dois códigos é escrito para trabalhar com malhas estruturadas! Isso quer dizer que, mesmo que a numeração dos volumes esteja sequencial, eles vão precisar de matrizes de conectividade. Tratando a "malha estruturada" como não estruturada. 

De qualquer forma, muitas malhas hexaédricas feitas, por exemplo, no ICEM, não são estruturadas (independendo do solver a ser utilizado). Quando se usa uma abordagem de blocos no ICEM para gerar uma malha hexaédrica, na maioria das vezes, por questões de complexidade geométrica, a malha não fica "estruturada", mas sim "estruturada por blocos" (dentro de cada bloco a numeração é sequencial). Na hora de transformar o pre-mesh do ICEM em malha (para CFX ou FLUENT) qual a opção usada? "Convert to unstructured mesh"! Fica claro não?

As malhas hexaédricas são trabalhosas de serem feitas, mas tem uma série de vantagens sobre as tetraédricas (mesmo com camadas de prismas) quando se tratam problemas de fluidodinâmica computacional. Porém, em muitos casos, não a de serem "estruturadas". Particularmente eu acho relaxante fazer malhas usando o blocking do ICEM, mas para a fluidodinâmica computacional esse fato é desprezível.

Bom, por hoje era isso então. 

Saudações.