Malha estruturada vs. Cálculo estruturado
Autor: Marco Leonardelli Lovatto | Publicado: 2011-09-23T21:03:00-03:00



Antes de qualquer coisa, o leitor deve estar ciente da diferença entre uma malha estruturada e uma malha não-estruturada. Ela está na representação da discretização espacial. A malha estruturada foi a primeira a aparecer, tem uma representação mais simples e é mais fácil de programar.&nbsp; Em contrapartida, a malha não-estruturada tem como vantagem a robustez (1) na representação de geometrias complexas e (2) no particionamento do domínio para paralelização. Aqui estamos falando de malha, e a equivalência vale para o cálculo: o cálculo estruturado (serial) é muito eficiente, enquanto o não-estruturado é mais complexo e demanda mais espaço de armazenamento.


Ora, a ideia então é que todos os softwares disponíveis no mercado sejam “pelo menos” estruturados, sendo um adicional a capacidade de suportar malhas não-estruturadas. Entretanto, fugindo da lógica aparente, não é assim que funciona.




Embora sua representação seja simples, criar uma malha estruturada em geometria complexa pode ser uma tarefa cansativa e demorada. Uma vez pronta a malha, a compensação viria na forma de um cálculo serial mais rápido, convergência mais simples e resultado mais confiável, poderíamos pensar. Mas lamento informar: ter uma malha estruturada não será garantia de que o cálculo também o será.













Como exemplo, dois dos softwares comerciais de CFD mais utilizados: STAR-CCM+ (CD-adapco) e CFX (ANSYS Inc.). Ambos os códigos são não-estruturados (e apenas não-estruturados). Isso significa que, ao carregar uma malha estruturada num solver não-estruturado, ou ela será convertida para uma representação não-estruturada ou, no pior dos casos, o solver simplesmente não lerá a malha.


Você poderia se perguntar por que isso, ao lembrar que a abordagem estruturada é mais antiga e mais simples de programar. Além disso, o cálculo estruturado serial também é mais eficiente...

A resposta a essa questão é fonte de um boato no qual acreditei até recentemente: de que existiriam restrições legais no fornecimento de códigos comerciais de cálculo estruturado a fim evitar o uso dos mesmos para 
fins militares. Entretanto, de acordo com Bruno Alexandre Contessi, da ESSS (fornecedora dos produtos e suporte ANSYS no Brasil), essa informação não procede.

As verdadeiras razões estão (1) no trabalho laborioso de geração de malha estruturada se não dispomos de softwares capazes de fazê-lo automaticamente (como TurboGrid ou ICEM Hexa, ambos da ANSYS) e (2) na vantagem do cálculo não-estruturado paralelizado. Então, as malhas não-estruturadas são, hoje, mais visadas pela indústria. Devidas às necessidades de aprimoramentos constantes, manter dois solvers (estruturado e não-estruturado), sendo um deles para resolver uma pequena classe de problemas, torna-se também inviável.


Nessas circunstâncias, o cálculo não-estruturado acaba sendo a única opção na maioria dos softwares comerciais. Uma exceção é Fine/Turbo (NUMECA), que é estruturado.


Sabemos agora que:

- uma malha estruturada não necessariamente será calculada como tal;
- um solver que suporta malha não-estruturada não necessariamente é capaz de cálculo estruturado.


É claro que os primeiros códigos CFD não suportavam malhas não-estruturadas porque só havia o método estruturado de cálculo. Suportar malhas não-estruturadas realmente é um ótimo avanço para qualquer solver, já tendo-se tornado uma tecnologia bem dominada. O problema é quando não se quer admitir que... hãã... bem... é que... na verdade... “nós não suportamos mais cálculo estruturado”.


São confusões que precisamos eliminar... e situações que precisamos suportar.