Meilleures méthodologies pour gérer un maillage en calcul par éléments finis parallèles?

Je développe actuellement une méthode de décomposition de domaine pour la solution du problème de diffusion. Fondamentalement, je résous un système de BVP Helmholtz de manière itérative. Je discrétise les équations en utilisant la méthode des éléments finis sur des maillages triangulaires ou tétraédriques. Je développe le code vers ma thèse de doctorat. Je connais certaines des bibliothèques d'éléments finis existantes telles que deal.ii ou DUNE et bien que je pense qu'elles sont excellentes, avec une conception inspirante et une API, à des fins d'apprentissage, je voulais développer ma propre petite application à partir de zéro.

J'en suis à un point où je fais tourner mes versions série et maintenant je veux les paralléliser. Après tout, c'est l'un des points forts du cadre de décomposition de domaine de formuler des algorithmes faciles à paralléliser, du moins en principe. En pratique cependant, il y a de nombreux détails à considérer. La gestion du maillage en fait partie. Si les applications doivent atteindre une résolution élevée tout en s'adaptant bien à de nombreux processeurs, la réplication d'un maillage entier sur chaque processeur est inefficace.

Je voulais demander aux développeurs qui travaillent sur des applications similaires dans des environnements informatiques à haute performance comment ils traitent ce problème.

Il existe une bibliothèque p4est pour la gestion distribuée du maillage. Je n'ai pas besoin d'AMR, donc cela pourrait être exagéré car je ne suis intéressé que par l'utilisation de maillages uniformes et je ne suis pas sûr qu'il puisse affiner les maillages triangulaires. Je pourrais également simplement créer un maillage uniforme, puis l'introduire dans l'un des séparateurs de maillage et effectuer un post-traitement de la sortie.

L'approche la plus simple semble créer un fichier séparé pour chaque partition contenant des informations de maillage pertinentes uniquement pour cette partition particulière. Ce fichier serait lu par une seule CPU qui serait responsable de l'assemblage du système discret sur cette portion du maillage. Bien sûr, certaines informations de connectivité / voisinage de partition globale devraient également être stockées dans un fichier lu par tous les processeurs pour la communication inter-processus.

Quelles autres approches existe-t-il? Si certains d'entre vous pourraient partager, quelles sont certaines des méthodologies couramment utilisées dans l'industrie ou les institutions de recherche gouvernementales liées au traitement de ce problème? Je suis assez nouveau dans la programmation d'un solveur par éléments finis parallèle et je voulais savoir si je pense correctement à ce problème et comment les autres l'abordent. Tout conseil ou pointeur vers des articles de recherche pertinents serait grandement apprécié!

Merci d'avance!

Si vous n'utilisez pas AMR et que vous ne souhaitez pas évoluer au-delà des cœurs 1K-4K, faites-le simplement.

1. Le rang 0 lit l'intégralité du maillage et le partitionne à l'aide de METIS / Scotch, etc. (Remarque: il s'agit d'une opération en série).

2. Le rang 0 diffuse les informations de partitionnement élément / nœud à tous les autres rangs et libère la mémoire (utilisée pour stocker le maillage)

3. Tous les rangs lisent les nœuds / éléments qu'ils possèdent (y compris les nœuds fantômes) à partir du même fichier d'entrée (Remarque: 2000 rangs accédant au même fichier d'entrée peuvent sembler lents mais ne sont pas en pratique, bien que cela puisse être mauvais pour le système de fichiers, mais nous le font qu'une seule fois).

4. Tous les rangs doivent créer les mappages de nœuds / éléments / dof locaux à globaux pour l'application des BC et l'assemblage des matrices et renuméroter les nœuds.

Une fois que tout est dit et fait, toutes les données d'un rang seront locales, vous devriez donc être en mesure de bien évoluer (en termes de mémoire). Je fais tout cela en environ 100 lignes (voir les lignes 35-132 ici ) dans un petit code à moi.

Maintenant, si votre maillage est trop grand (par exemple,> 100-250 millions d'éléments) que vous ne pouvez pas le partitionner en utilisant METIS sur un seul nœud et que vous avez besoin de ParMETIS / PT-Scotch, vous avez le travail supplémentaire de le partitionner en parallèle avant tous les cœurs / les rangs peuvent le lire. Dans un tel scénario, il pourrait être plus facile de séparer la phase de partitionnement du code principal pour des raisons logistiques.

Les bibliothèques Btw AMR ne font généralement pas de tets. PETSc est également un bon choix pour la parallélisation de votre code.

Edit: Voir aussi ici et ici .

Cela peut ne pas vous surprendre étant donné que je développe deal.II, mais voici mon point de vue: lorsque je parle aux étudiants, je leur dis généralement de développer leur propre prototype au début afin qu'ils puissent voir comment cela se fait. Mais ensuite, une fois qu'ils ont quelque chose de petit, je leur fais utiliser une bibliothèque qui leur permet d'aller tellement plus loin car ils n'ont pas à réinventer la roue à chaque pas qu'ils font.

Dans votre cas, vous avez déjà vu comment implémenter un simple solveur Helmholtz. Mais vous passerez les 6 prochains mois à écrire le code nécessaire pour le faire en parallèle, vous passerez encore 3 mois si vous souhaitez utiliser des géométries plus compliquées. Vous passerez ensuite 6 mois de plus si vous voulez un solveur efficace. Et pendant tout ce temps, vous écrivez du code qui a déjà été écrit par quelqu'un d'autre et qui, dans un sens, ne vous rapproche pas de ce que vous devez réellement faire pour votre doctorat: développer quelque chose de nouveau qui n'a pas été fait avant. Si vous suivez cette voie, vous passerez 2-3 ans de votre doctorat à refaire ce que d'autres ont fait, et peut-être 1 an à faire quelque chose de nouveau.

L'alternative est que vous passez maintenant 6 mois à apprendre l'une des bibliothèques existantes, mais après cela, vous aurez 2-3 ans où vous faites vraiment de nouvelles choses, des choses où toutes les deux semaines vous pouvez entrer dans le bureau de votre conseiller et lui montrer / son quelque chose de vraiment nouveau, qui fonctionne à grande échelle, ou qui est tout simplement très cool à d'autres égards. Je pense que vous voyez probablement où je veux en venir maintenant.

Ce n'est pas une réponse complète.

Pour la mise en œuvre de méthodes de décomposition de domaine parallèle, j'ai rencontré quelques complications. Premièrement, on peut utiliser plusieurs processeurs pour un sous-domaine ou alimenter un processeur avec plusieurs sous-domaines et on peut vouloir implémenter les deux paradigmes. Deuxièmement, la forme sous-structurée des méthodes de décomposition de domaine nécessite de séparer les faces, les arêtes et les sommets des sous-domaines (et non des éléments). Je ne pense pas que ces complications soient facilement incluses dans la gestion du maillage parallèle. La situation devient plus simple si vous considérez un processeur pour un sous-domaine et utilisez la méthode RAS / RASHO qui se chevauchent. Même dans ce cas, vous feriez mieux de gérer vous-même votre disposition parallèle,