Este artigo foi atualizado. Clique aqui para acessar a versão mais recente.
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. 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.
Este artigo foi atualizado. Clique aqui para acessar a versão mais recente.
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.
Este artigo foi atualizado. Clique aqui para acessar a versão mais recente.
É 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.
Nenhum comentário:
Postar um comentário