Melhores metodologias para gerenciar uma malha na computação paralela por elementos finitos?

Atualmente, estou desenvolvendo um método de decomposição de domínio para a solução do problema de espalhamento. Basicamente, estou resolvendo um sistema de Helmholtz BVPs iterativamente. Discreto as equações usando o método dos elementos finitos sobre malhas triangulares ou tetraédricas. Estou desenvolvendo o código para minha tese de doutorado. Estou ciente de algumas das bibliotecas de elementos finitos existentes no mercado, como deal.ii ou DUNE, e embora elas sejam ótimas, com design inspirador e API, para fins de aprendizado, eu queria desenvolver meu próprio aplicativo a partir do zero.

Estou em um ponto em que tenho minhas versões seriais em execução e agora quero paralelizá-las. Afinal, é um dos pontos fortes da estrutura de decomposição de domínio formular algoritmos fáceis de paralelizar, pelo menos em princípio. Na prática, porém, há muitos detalhes que se deve considerar. O gerenciamento de malha é um deles. Se os aplicativos atingirem alta resolução enquanto escalam bem para muitas CPUs, a replicação de uma malha inteira em cada CPU é ineficiente.

Eu queria perguntar aos desenvolvedores que trabalham em aplicativos semelhantes em ambientes de computação de alto desempenho como eles lidam com esse problema.

Existe uma biblioteca p4est para gerenciamento de malha distribuída. Eu não preciso de AMR, portanto pode ser um exagero, pois estou interessado apenas em usar malhas uniformes e não tenho certeza se ele pode refinar malhas triangulares. Eu também poderia simplesmente criar uma malha uniforme, depois alimentá-la em um dos particionadores de malha e fazer algum processamento posterior da saída.

A abordagem mais simples parece criar um arquivo separado para cada partição que contém informações de malha relevantes apenas para essa partição específica. Esse arquivo seria lido por uma única CPU, responsável pela montagem do sistema discreto naquela parte da malha. Obviamente, algumas informações de conectividade / vizinhança da partição global também precisariam ser armazenadas em um arquivo lido por todas as CPUs para comunicação entre processos.

Que outras abordagens existem por aí? Se alguns de vocês pudessem compartilhar, quais são algumas das metodologias mais usadas no setor ou nas instituições governamentais de pesquisa relacionadas ao tratamento desse problema? Eu sou muito novo na programação de um solucionador de elementos finitos paralelo e queria ter uma idéia se estou pensando ou não sobre esse problema corretamente e como os outros estão se aproximando. Qualquer conselho ou indicação de artigos de pesquisa relevantes seria muito apreciado!

Desde já, obrigado!

Se você não estiver usando AMR e não quiser escalar além dos núcleos 1K-4K, basta fazer isso.

1. A classificação 0 lê toda a malha e a particiona usando METIS / Scotch etc. (Nota: Esta é uma operação serial).

2. O posto 0 transmite as informações de particionamento de elemento / nó para todos os outros níveis e libera a memória (usada para armazenar a malha)

3. Todas as classificações leem os nós / elementos que possuem (incluindo nós fantasmas) do mesmo arquivo de entrada (Nota: as classificações de 2000 que acessam o mesmo arquivo de entrada podem parecer lentas, mas não são práticas, embora possam ser ruins para o sistema de arquivos, mas nós estão fazendo isso apenas uma vez).

4. Todos os níveis precisam criar mapeamentos de nó / elemento / dof local para global para aplicação de BCs e montagem de matrizes e renumerar os nós.

Depois de tudo dito e feito, todos os dados em uma classificação serão locais, portanto, você poderá escalar bem (em memória). Eu faço tudo isso em cerca de 100 linhas (veja as linhas 35-132 aqui ) em um pequeno código meu.

Agora, se sua malha é muito grande (por exemplo,> 100-250 milhões de elementos), você não pode particioná-la usando o METIS em um único nó e precisa do ParMETIS / PT-Scotch, então você tem o trabalho adicional de particioná-la em paralelo antes de todos os núcleos / fileiras podem lê-lo. Nesse cenário, pode ser mais fácil manter a fase de particionamento separada do código principal por razões logísticas.

Btw AMR libs geralmente não fazem tets. O PETSc também é uma boa opção para paralelização do seu código.

Edit: Veja também aqui e aqui .

Isso pode não ser uma surpresa para você, uma vez que desenvolvo um acordo.II, mas eis a minha perspectiva: quando falo com os alunos, normalmente digo a eles que desenvolvam seu próprio protótipo no começo para que possam ver como é feito. Mas então, uma vez que eles têm algo pequeno em execução, eu os faço usar uma biblioteca que lhes permite ir muito mais longe, porque eles não precisam reinventar a roda com basicamente todos os passos que dão.

No seu caso, você já viu como implementar um simples solucionador de Helmholtz. Mas você passará os próximos 6 meses escrevendo o código necessário para fazê-lo em paralelo; você passará outros 3 meses se desejar usar geometrias mais complicadas. Você passará mais 6 meses se quiser um solucionador eficiente. E todo esse tempo você está escrevendo um código que já foi escrito por outra pessoa e que, em certo sentido, não o aproxima do que realmente precisa fazer pelo seu doutorado: desenvolva algo novo que não foi feito antes. Se você seguir esse caminho, passará de 2 a 3 anos do seu doutorado refazendo o que outros fizeram e talvez 1 ano fazendo algo novo.

A alternativa é que agora você passa 6 meses aprendendo uma das bibliotecas existentes, mas depois disso você terá 2-3 anos em que realmente faz coisas novas, coisas em que a cada duas semanas você pode entrar no escritório do consultor e mostrar-lhe / ela é algo verdadeiramente novo, que funciona em escalas massivamente grandes, ou é muito legal em outros aspectos. Eu acho que você provavelmente já vê onde estou indo com isso agora.

Esta não é uma resposta completa.

Para a implementação de métodos de decomposição de domínio paralelo, encontrei algumas complicações. Primeiro, pode-se usar muitos processadores para um subdomínio ou alimentar um processador com muitos subdomínios e pode-se implementar dois paradigmas. Segundo, a forma subestruturada de métodos de decomposição de domínio requer a separação de faces, arestas e vértices dos subdomínios (não dos elementos). Eu não acho que essas complicações sejam prontamente incluídas no gerenciamento de malha paralela. A situação se torna mais simples se você considerar um processador para um subdomínio e usar o método RAS / RASHO sobreposto. Mesmo nesse caso, você gerenciaria melhor seu layout paralelo,