Wizualizacja nieciągłych danych Galerkina / elementu skończonego

Chciałbym wizualizować wyniki symulacji uzyskane przy użyciu nieciągłego podejścia Galerkin (DG) w ramach ParaView. Podobnie jak w przypadku metod o skończonej objętości, dziedzina problemowa jest podzielona na komórki w kształcie sześcianu („elementy”). W przeciwieństwie do metod o skończonej objętości, w każdej komórce jest nie tylko jedna wartość dla wektora rozwiązania , ale każda komórka zawiera rozwiązanie u w wielu punktach integracji Gaussa.$\mathbf{u}$$\mathbf{u}$

Moje pytanie brzmi: czy ktoś ma doświadczenie w wydajnej wizualizacji takich danych w ParaView / VTK i jakie podejście wybrałeś do reprezentowania danych w VTK. Przychodzi mi na myśl kilka możliwych sposobów, ale nie wiem, który z nich jest najbardziej obiecujący:

(1) Użyj wokseli
Użyj jednego woksela dla każdego punktu integracji.
Pro: Wszystkie wtyczki, które działają ze standardowymi nieustrukturyzowanymi typami komórek VTK, będą działać bez żadnych zmian.
Przeciw: Ponieważ punkty integracji nie są rozmieszczone równomiernie, znalezienie właściwej lokalizacji wierzchołków może być trudne. Rozwiązanie można również zdefiniować dwukrotnie na powierzchniach komórek, ponieważ szkielet DG umożliwia rozwiązania nieciągłe. Również informacje hierarchiczne (domena podzielona na elementy, każdy element zawiera kilka punktów) są tracone.

(2) Użyj wielowertorów
Użyj jednego wierzchołka na punkt integracji.
Pro: Najłatwiejszy do wdrożenia, łatwy do określenia wielu punktów w tej samej lokalizacji za pomocą różnych rozwiązań.
Wada: możliwość wizualizacji danych jako „komórek” zostaje utracona, plus te same wady co powyżej.

(3) Użyj schematu kwadraturowego VTK
Użyj wbudowanej obsługi schematów kwadraturowych.
Pro: Raczej prosta implementacja, zachowuje wszystkie relacje i właściwości oryginalnego rozwiązania.
Przeciw: Ponieważ jest to całkowicie nowy typ komórki, wiele (większość) istniejących wtyczek nie będzie już działać i prawdopodobnie trzeba będzie je przepisać.

deal.II używa opcji (2) już od dawna z bardzo dobrym skutkiem. Innymi słowy, w 2d każdy wierzchołek pojawia się 4 razy w pliku wyjściowym, co oznacza, że ​​jest więcej danych do zapisania, ale pola mogą być nieciągłe. Jedyną inną wadą, o której wiem, jest to, że niektóre programy do wizualizacji nie mogą podążać za interfejsami między komórkami, które nie dzielą wierzchołków podczas robienia usprawnień, choć dziś wydają się być lepsze.

Możesz także zajrzeć do tego wpisu w często zadawanych pytaniach: http://dealii.sourceforge.net/index.php/Deal.II_Questions_and_Answers#The_graphical_output_files_don.27t_make_sense_to_me_.E2.80.94_they_seem_to_free_re_ree_re_re_ree_re_re_re_re_re_re_re_re_re_re_re_re_re_re_re_re_e_e_free_re_re_re_ree_re_e_e_free

Aktualizacja: 31 maja 2018 r

Link został przeniesiony do: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#the-graphical-output-files-dont-make-sense-to-me----they- wydaje się, że ma za dużo stopni swobody