Visualisation des grilles quadtree et octree

Les grilles dites quadtree et octree sont très intéressantes pour les applications nécessitant un raffinement adaptatif du maillage. Ils sont par exemple utilisés à Gerris et Paramesh . Quelqu'un connaît-il un bon format de fichier pour de telles grilles et un logiciel de visualisation compatible? Voir également cette réponse dans la FAQ Gerris. Le seul candidat potentiel que je connaisse actuellement est la classe VTK HyperOctree , mais il semble qu'il n'y ait presque aucune documentation.

Comme exemple spécifique d'un maillage, considérons une grille d'octree peu raffinée, composée de cases, chacune contenant cellules. Mes stratégies actuelles dans Visit / Paraview sont: $10^4$ $8 \times 8 \times 8=512$

Écrivez la grille en tant que fichier VTK non structuré. Cela coûte cher pour des ensembles de données plus importants et n'exploite pas la «structure» du quad / octree.
Rassemblez les «boîtes» voisines de l'arbre en blocs plus grands et écrivez une grille structurée en blocs. Cela implique un peu de code supplémentaire et perd les informations de connectivité intégrées dans le quad / octree.

Mise à jour S'il n'y a actuellement aucun format viable pour écrire et visualiser directement une grille d'octree, j'apprécierais des suggestions pour un format de fichier qui peut être utilisé pour écrire l'octree comme une grille structurée en blocs. Idéalement, ce format:

A une définition / implémentation relativement simple, idéalement open source et compatible avec C / Fortran.
Peut gérer efficacement un grand nombre de blocs de grille (par exemple 1000 ou plus).
Permet de spécifier facilement la connectivité des blocs de grille, en particulier aux limites du raffinement.

J'utilise actuellement Silo à cette fin, mais je cherche quelque chose qui marque mieux sur les trois points ci-dessus (plus petit, plus rapide, plus simple).

visualization Jannis Teunissen
la source

Pourquoi le maillage non structuré crée-t-il trop de données? Ce ne serait que 5 millions de cellules. C'est un assez petit ensemble de données que je peux visualiser dans Visit ou Paraview.

Wolfgang Bangerth

Parce que les coordonnées et la connectivité sont spécifiées par cellule, au lieu d'une seule fois par boîte (contenant par exemple 512 cellules). Pour les ensembles de données plus volumineux (par exemple, 20 millions de cellules ou plus), la visualisation devient beaucoup plus lente qu'avec un maillage structuré en blocs, en particulier si des parties importantes de la grille sont au même niveau de raffinement.

Jannis Teunissen

La liste des formats de fichiers pris en charge dans Visit est peut-être utile pour cette question: visitusers.org/…

Jannis Teunissen

Peut-être aussi regarder ce que CHOMBO, SAMRAI etc. font pour la visualisation?

Abhilash Reddy M

Ajoutez BoxLib à la liste. Ils ont développé un package appelé AMRVis pour visualiser les données AMR. Le code est disponible sur le site Web de LBL.

Abhilash Reddy M

Réponses:

Dans mon cas, lorsque je faisais le raffinement à plusieurs niveaux, j'avais l'habitude d'écrire des fichiers de grille à différents niveaux séparément. Habituellement, le niveau 0 est un maillage grossier de base qui reste fixe. Et pour le niveau 1 et plus, j'ai utilisé différents fichiers pour différents patchs. Supposons que si vous avez 5 correctifs corrects au niveau 1, ma stratégie était d'écrire cinq fichiers différents à la fin de mon programme, quelque chose comme Level_1_Patch_1, Level_1_Patch_2 ... qui pourrait être fait dynamiquement en C (jamais travaillé dans Fortran).

        char filename1[64];
        sprintf(filename1, "Patch%d.dat", patch_number);

        FILE *file;
        file= fopen(filename1, "wb");

Je dois mentionner ici que j'ai utilisé un système de grille structurée à différences finies.

Donc une fois j'ai eu tous les niveaux et leurs fichiers .PLT ou .DAT. Je les importe tous dans TecPLOT. Par exemple, lorsque j'écrivais mon code à deux niveaux avec quelques correctifs fins au niveau 1, votre maillage devrait ressembler à ceci dans Tecplot.

Je ne suis pas très familier avec la manipulation des grilles non structurées mais celles structurées sont bien gérées dans Tecplot

Tanmay Agrawal
la source

Intéressant à lire sur votre approche, mais cela ne semble pas viable pour un grand octree, alors vous devrez écrire et lire des milliers de fichiers, ce qui est généralement assez lent.

Jannis Teunissen

@JannisTeunissen: Si vous optez pour une solution structurée par blocs, pour Tecplot, tous les blocs peuvent être écrits dans le même fichier que des "Zones" séparées (terminologie tecplot). Ils ne doivent pas nécessairement être des fichiers séparés. Cependant, les E / S parallèles ne sont pas là. Les grands ensembles de données s'étoufferont. Les fichiers tecplot peuvent être chargés dans ParaView (Tecplot est propriétaire). Le format ascii est très simple. Avec un peu d'effort, vous pouvez également écrire directement des fichiers binaires au format tecplot. Il existe une bibliothèque officielle appelée TecIO que vous pouvez lier votre code pour créer les fichiers plus facilement.

Abhilash Reddy M

Je ne pense pas que cela fonctionnerait mieux que mon approche actuelle avec Silo, qui (surtout) est open source. Notez que les fichiers ASCII ne sont pas vraiment viables pour ce problème.

Jannis Teunissen