» Blog » Połączenia między siatkami

Połączenia między siatkami

W analizach CFD złożenie domeny obliczeniowej z wielu ciał budzi wiele wątpliwości. W jaki sposób budowana jest siatka na połączeniu? Jak realizowany jest przepływ przez połączenie, i czy w ogóle jest sens dzielić domenę na mniejsze obszary – to pytania które często pojawiają się u użytkowników. Niniejszym artykułem postaramy się rozwiać wszelkie wątpliwości w tym temacie.

Przede wszystkim, odpowiedzmy sobie na pytanie – w jakim celu dzielić domenę. Wydaje się oczywiste, że w przypadku gdy mamy do czynienia z kilkoma materiałami w jednej symulacji, muszą one być przypisane do odrębnych obszarów. Obszary te, we Fluencie nazywane CellZone’ami, a w CFXie Domenami również mogą być podzielone i składać się z kilku mniejszych ciał. A zatem użytkownik musi zadbać nie tylko o połączenia między różnymi typami materiałów, ale również, jeśli uzna za stosowne podzielić materiał na mniejsze kawałki, w obrębie jednego obszaru.

Ale dlaczego w takim razie, chcielibyśmy podzielić domenę w ramach jednego materiału? Powodów jest kilka. Po pierwsze – domeny obrotowe. W modelach gdzie element obrotowy stanowi jedynie ułamek całkowitej objętości obszaru zainteresowania (np. mieszalnik), często wycina się z objętości płynu domenę w kształcie cylindra. Ruch elementu zadaje się wtedy nie do samego wirnika, lecz do całej domeny w której „zatopiony” jest obiekt (modele Sliding Mesh oraz Transient Rotor Stator). Jest to bardzo częsta praktyka, której główną zaletą jest to, że obrót elementu nie powoduje deformacji siatki, a w ostateczności kosztownego remeshingu.

Druga sytuacja, to taka w której dzielimy domenę w celu usprawnienia procesu siatkowania. Zwykle przy dużych zadaniach warto podzielić model na mniejsze fragmenty aby łatwiej i szybciej wygenerować siatkę. Mniejsze porcje domeny do przesiatkowania pozwalają na przetestowanie lokalnych ustawień siatki bez konieczności generowania siatki w całej domenie. Ponadto, dużo łatwiej jest zdiagnozować problemy siatki i poszukać odpowiedniego rozwiązania.

Wyobraźmy sobie sytuację, w której nasza siatka składa się z 20 milionów elementów. Wygenerowanie jej zajmuje kilkanaście minut. Jeżeli podzielimy zadanie na 10 części, to przy założeniu że każda z części ma podobną ilość elementów, wygenerowanie jednej części zajmie maksymalnie kilka minut. Oczywiście nie jest to zależność liniowa i ciężko jednoznacznie stwierdzić o ile szybciej wygenerujemy siatkę kawałka w stosunku do całości, to jednak z całą pewnością dużo szybciej dojdziemy do rozwiązania potencjalnego problemu jeśli skupimy się jedynie na wycinku, w którym zlokalizowany jest problem niż tworzyć całą siatkę za każdym razem gdy wprowadzimy jakieś zmiany.

Często taki podział może być wykonany celem stworzenia siatki hybrydowej. Siatka taka, to nic innego jak połączenie siatki tetrahedralnej z hexahedralną. Ideą jest wygenerowanie siatki hexahedralnej w miejscach geometrycznie prostych (np. prostopadłościany, bryły wyciągane po ścieżce), oraz tetrahedralnej w miejscach skomplikowanych. Dla wielu przypadków, siatka hybrydowa da mniej elementów w stosunku do siatki tetrahedralnej, jednak nie jest to reguła. Z drugiej strony, nawet jeśli otrzymamy podobną ilość elementów, siatki hexahedralne zawsze są porządane, nawet jeśli wygenerowane zostaną tylko w części domeny.

Ostatni przykład dzielenia domeny to sytuacja w której użytkownik chciałby zadać dodatkowe warunki do określonego obszaru. Mówimy tu na przykład o objętościach porowatych czy źródłach objętościowych. Dla przykładu, chcąc zamodelować grzałkę możemy ograniczyć się do wydzielenia strefy w której ta grzałka pracuje i do danej lokalizacji przypisać źródło ciepła oraz zadać opory przepływu. Otrzymamy w ten sposób globalny efekt działania grzałki bez konieczności uwzględniania jej skomplikowanej geometrii.

Niezależnie od motywacji jaka kierowała użytkownika, zastanówmy się teraz, co się dzieję, gdy siatkujemy tak podzieloną wcześniej domenę. Ogólnie rzecz ujmując, rozróżniamy dwa podejścia do siatek wielobryłowych: Wspólna Topologia (Shared Topology) oraz Interface’y. Zasadnicza różnica pomiędzy nimi to kwestia, czy siatki poszczególnych brył są od siebie zależne, i czy w ostateczności wytworzymy siatkę spójną. We wspólnej topologii siatka w miejscu łączenia brył jest współdzielona. Innymi słowy siatkując kolejne bryły modelu nowe siatki muszą dopasować się do tego co już zostało zrobione. Z punktu widzenia samych obliczeń jest to pożądane rozwiązanie, gdyż nie wymaga żadnych dodatkowych zabiegów i informacje mogą swobodnie przepływać przez połączenie.

Z kolei użycie Interface’ów całkowicie rozpina siatki i każda z nich generowana jest niezależnie od pozostałych. To oczywiście skutkuje w dodatkowych obliczeniach solwera, który musi interpolować wartości z jednej strony Interface’u na drugi. W teorii więc, to wspólna topologia powinna dać dokładniejszy rezultat. Należy tu jednak zaznaczyć, że dobrze wykonane Interfejsy dadzą ten sam końcowy rezultat co Wspólna Topologia.

Aby rezultaty obydwu metod nie odbiegały znacząco od siebie należy spełnić dwa podstawowe warunki: ten sam (lub przynajmniej zbliżony) rozmiar elementu po obydwóch stronach interface’u, oraz zadbanie o jak najdokładniejsze spasowanie powierzchni interface’u. Pierwszy z warunków wydaje się oczywisty – wartości przepływowe uśredniane są w całej objętości komórki. Jeżeli zatem spróbujemy przetransferować informację z siatki o małych elementach do siatki dużo rzadszej, dokładność tej pierwszej zostaje utracona i interfejs jest nie konserwatywny.

Wyjątkiem od reguły tego samego rozmiaru elementu są połączenia typu płyn-ciało stałe (analizy CHT). W przypadku analiz wnikania ciepła z płynu do ciała stałego rozmiar elementu w ciele stałym może być dużo większy niż ten w płynie. Jest to wyjątkowo korzystne podejście z punktu widzenia ilości elementów siatki. Najczęściej mamy do czynienia z sytuacją gdzie po stronie płynu generuje się dużo mniejsze elementy w stosunku do ciał stałych. Chcąc zachować ten sam rozmiar po dwóch stronach interfejsu wymuszamy bardzo gęstą siatkę po stronie ciała stałego. Taka sytuacja będzie mieć również miejsce w metodzie wspólnej topologii.

Szczególną ostrożność należy zachować przy tworzeniu interfejsów na zaokrąglonych powierzchniach. Wtedy, obszary takie są wyjątkowo wrażliwe na różnice w rozmiarach elementów oraz niedostatecznie dobre odwzorowanie krzywizny. W skrajnych sytuacjach, gdzie ściany elementów większych przenikają te mniejsze w znacznym stopniu, może dojść do rozerwania komunikacji między stronami interfejsów.

Nie należy również zapominać o odpowiednim podziale brył. Podziały domeny najlepiej przeprowadzać w miejscach, gdzie powierzchnie interfejsu będą się idealnie pokrywać. Jeśli nie jest to możliwe konieczne jest zrzutowanie mniejszego interfejsu na większy. Jeśli tego nie zrobimy w wynikach pojawi się rozmyta krawędź interfejsu i numeryczne artefakty.

Czy Shared Topology również obarczony jest tyloma wymaganiami? Odpowiedź brzmi „nie”. Jednakże, to nie oznacza że ST nie przysparza żadnych kłopotów. Wręcz przeciwnie – przy skomplikowanej geometrii mogą pojawić się problemy przy próbie utworzenia wspólnej topologii. O jakich sytuacjach mówimy? Na pewno należy zadbać o to, by powierzchnie styku idealnie się pokrywały w obszarze kontaktu. Niemożliwe jest łączenie powierzchni typu Plane z powierzchnią opisaną wielomianem (Spline). Czasami, problemy powodują powierzchnie wyższego rzędu styczne do powierzchni kontaktu. Nieraz, niewielka niedokładność na obszarze kontaktu, powoduje że operacja wspólnej topologii jest niezwykle trudna.

Można w tym miejscu postawić pytanie: skoro wspólna topologia daje dokładniejszy wynik, a interfejsy obarczone są tyloma obostrzeniami, dlaczego w ogóle chcielibyśmy używać tej drugiej metody? Pomijając sytuację, w których musimy użyć siatki niespójnej (domeny obrotowe), lub chcemy zredukować ilość elementów w analizie CHT, siatkowanie „osobno” daje możliwość generowania siatki równolegle, co w przypadku dużych modeli okazuje się być nieocenione. Korzystając z ANSYS Meshing możliwe jest użycie po jednym rdzeniu procesora na każdą osobną część w trybie ineterfejsów (bez dodatkowych licencji!). W praktyce, takie modele które na Wspólnej Topologii siatkują się kilkadziesiąt minut, na Interface’ach wygenerują się w kilka minut.
Z drugiej strony, użycie Wspólnej Topologii nie wymaga żadnych dodatkowych operacji ze strony użytkownika. Nie ma również konieczności zagłębiania się i szczegółowego kontrolowania połączeń między bryłami. O ile geometria została przygotowana poprawnie Wspólna Topologia jest właściwie bezobsługowa. To z kolei jest cenne dla początkujących użytkowników.
Ponieważ w ostatecznym rozrachunku wynik symulacji będzie ten sam, wybór metodologii zależy głównie od wielkości i poziomu skomplikowania modelu oraz stopnia zaawansowania użytkownika.

Obserwując dostępne narzędzia na rynku symulacji, bardzo trudno jest o algorytmy siatkowania równoległego*. Mimo iż możemy uruchomić obliczenia na dowolnej liczbie rdzeni, to sam proces siatkowania często jest tzw. „wąskim gardłem” i wykonywany na jednym rdzeniu, bardzo mocno wydłuża proces symulacji. Siatkowanie podzielonej domeny, bez spójnej siatki stanowi zatem pewnego rodzaju substytut pełnego siatkowania równoległego.
Z tego też powodu, obecnie obserwuje się wzrost popularności metody z Interfece’ami. Mają na to wpływ: co raz większa powszechność wielordzeniowych procesorów w stacjach roboczych oraz duży rozwój funkcjonalności oprogramowania pod kątem tworzenia i obróbki Interface’ów. Korzystając z ANSYS Meshing użytkownik może chociażby skorzystać z automatycznego narzędzia do wykrywania i nazywania interface’ów. Dużo w tej dziedzinie zrobiono również w nowych wersjach Fluenta. W wersji 18 przebudowano interfejs graficzny narzędzia do obróbki Interface’ów, dodając równocześnie funkcjonalność automatycznego ich tworzenia z par Named Selections.


Dla osób chcących poznać jak stworzyć siatkę spójną i niespójną polecam obejrzeć nasze materiały w serwisie YouTube:

Siatka spójna:

Siatka niespójna:

*Choć należałoby tutaj wspomnieć o nadchodzącej technologii Mosaic i algorytmach typu Poly-Hexcore, będących już wkrótce dostępnych w środowisku Fluent Meshing.

Autor: Maciej Kryś