Views

Biuletyn nr 5

From KDMwiki

Jump to: navigation, search
Biuletyn KDM
1 | 2 | 3 | 4 | 5
6 | 7 | 8 | 9 | 10
11 | 12 | 13 | 14
15 | 16 | 17 | 18
19 | 20 | 21 | 22
23 | 24 | 25 | 26
27 | 28 | 29 | 30
31 | 32
Lista biuletynów

Biuletyn nr 5 (27 października 2005).

Spis treści

Programowanie: MPI

Autor: Konrad Wawruch

Wprowadzenie

W programowaniu równoległym mamy wiele podejść do kwestii wymiany danych między poszczególnymi procesami obliczeniowymi, w ramach jednego zadania równoległego. Począwszy od modeli, w których każdy proces ma bezpośredni dostęp do pamięci wszystkich pozostałych procesów (rozwiązanie rzadko spotykane w praktyce, poza komputerami o pamięci współdzielonej fizycznie), poprzez bezpośredni dostęp tylko do części danych, deklarowanych jako współdzielone (przykładem jest Co-Array Fortran, opisywany w poprzednim biuletynie), aż do modeli, w których nie ma bezpośredniego dostępu do pamięci innych procesów obliczeniowych, a wszelka wymiana danych z innymi procesami musi zachodzić przy współpracy stron, poprzez wymianę komunikatów.

MPI, czyli Message Passing Interface, jest przykładem ostatniego podejścia. Procesy obliczeniowe są uruchamiane oddzielnie na każdym węźle obliczeniowym lub procesorze, a do komunikacji służą wywołania funkcji biblioteki komunikacyjnej MPI.

Biblioteka MPI może być używana z poziomu C oraz Fortranu. Według mojego rozeznania, większa liczba użytkowników ICM używa Fortranu, z tego powodu wszelkie przykłady w artykule są podane dla tego języka. Użycie biblioteki MPI z C jest bardzo podobne -- zmienia się sposób podawania niektórych argumentów funkcji MPI, ze względu na różnice między Fortranem i C.

Istnieją 2 ważne wersje standardu MPI: 1.1 oraz 2.0. Wersja 2.0 usprawnia wiele mechanizmów oraz umożliwia dynamiczne zarządzenie procesami. Ze względu na wstępny charakter tego artykułu, skupimy się na wersji 1.1 standardu.

Podstawy

Tworzenie programu używającego biblioteki MPI różni się nieco od używania innych, normalnych bibliotek. Na etapie kodowania jest to używanie zwykłych wywołań procedur MPI. Ponieważ w efekcie chcemy uzyskać program równoległy, kompilacja oraz uruchamianie wygląda nieco inaczej, używa się do tego kompilatora mpif77 lub mpif90, do uruchamiania takich zadań służą programy mpirun oraz mpiexec.

Zacznijmy od kodowania. Jak już wiemy, na każdym węźle obliczeniowym/procesorze uruchomiony jest oddzielny proces. W celu użycia biblioteki MPI, musimy dokonać jej inicjalizacji na początku programu:

call MPI_Init(ierr)

Parametr ierr zawiera status wykonania procedury (w tym artykule, ze względu na wstępny charakter, pominięto analizę sytuacji wyjątkowych).

Podobnie przed zakończeniem wykonania programu musimy poinformować MPI o zakończeniu pracy:

call MPI_Finalize(ierr)

Pozwólmy teraz procesowi obliczeniowemu zorientować się w otoczeniu: ile procesów uczestniczy w obliczeniach, oraz jaki jest wśród nich numer danego procesu:

call MPI_Comm_Rank(MPI_Comm_World,imy_rank,ierr)
call MPI_Comm_Size(MPI_Comm_World,inp,ierr)

Pierwsza procedura pozwala poznać numer danego procesu imy_rank, druga -- liczbę procesów inp. Parametr MPI_Comm_World informuje MPI, że jesteśmy zainteresowani danymi globalnymi (całego świata) -- MPI umożliwia również tworzenie mniejszych grup procesorów, w celu ułatwienia wykonywania pewnych operacji.

Komunikacja

Zajmijmy się teraz komunikacją. Możliwości jest wiele:

  • komunikacja punkt-punkt asynchroniczna
  • komunikacja punkt-punkt synchroniczna
  • komunikacja grupowa: wysyłanie z jednego węzła do wszystkich pozostałych w grupie, zbieranie wartości ze wszystkich węzłów w grupie na jednym, wymiana danych każdy z każdym itp.

Użycie synchronicznej komunikacji punkt-punkt polega na wywołaniu, odpowiednio w dwóch procesach, następujących procedur:

call MPI_Send(x, 1, MPI_Real, t, tag, MPI_Comm_World, ierr)
call MPI_Recv(x, 1, MPI_Real, f, tag, MPI_Comm_World, istatus, ierr)

gdzie znaczenie poszczególnych parametrów jest następujące:

  • x -- zmienna do wysłania, typu Real
  • 1 -- długość danych, w tym wypadku pojedyncza liczba
  • MPI_Real -- określenie typu wysyłanych danych
  • f oraz t -- odpowiednio, numer procesora źródłowego oraz docelowego
  • tag -- znacznik komunikatu (możliwe jest odbieranie wiadomości tylko o zadanej wartości znacznika)
  • MPI_Comm_World -- określenie grupy komunikacyjnej, w której otrzymaliśmy numer procesu
  • ierr -- wynik działania procedury
  • istatus -- otrzymany status komunikacji

Komunikacja synchroniczna, mimo że wymaga spotkania się czasowego procesów, jest łatwiejsza do opanowania -- nie musimy sobie radzić z przepełnianiem buforów następującym w komunikacji asynchronicznej. Jakikolwiek błąd szybko prowadzi zazwyczaj do zablokowania się programu w oczekiwaniu na komunikację, co ułatwia jego zaobserwowanie.

Pisanie złożonych programów przy użyciu komunikacji punkt-punkt jest możliwe, jednak uciążliwe. Znacznie praktyczniejsze jest użycie procedur komunikacji grupowej. Najczęściej używane jest rozsyłanie przez jeden proces danych do wszystkich pozostałych w grupie, a następnie, po pewnych obliczeniach, gromadzenie wszystkich wyników:

call MPI_Bcast(x, 1, MPI_Integer, 0, MPI_Comm_World, ierr)        
call MPI_Reduce(r, rw, 1, MPI_Real, MPI_SUM, 0, MPI_Comm_World, ierr)
  • x -- zmienna do wysłania, typu Integer
  • r -- zmienna zawierająca dla każdego procesu liczby do scalenia, typu Real
  • rw -- zmienna zawierająca wynik scalania
  • 1 -- długość danych, w tym wypadku pojedyncza liczba
  • MPI_Real/MPI_Integer -- określenie typu wysyłanych danych
  • 0 -- numer procesora rozsyłającego i zbierającego dane
  • MPI_Comm_World -- określenie grupy komunikacyjnej, w której otrzymaliśmy numer procesu
  • ierr -- wynik działania procedury
  • MPI_SUM -- rodzaj operacji wykonywanej przy zbieraniu wyników, w tym wypadku sumowanie

W przypadku programowania z użyciem komunikacji synchronicznej, raczej nie potrzebujemy używać synchronizacji procesów. Jeśli jednak chcemy to zrobić, możemy użyć procedury:

call MPI_Barrier(MPI_Comm_World, ierr)

Procedura ta zakończy działanie jednocześnie na wszystkich procesach w grupie, w momencie kiedy każdy proces dotrze do tego miejsca w kodzie.

W powyższej części artykułu wielokrotnie padało określenie grup procesów. Standardowa grupa, MPI_Comm_World, obejmuje wszystkie procesy. Możemy jednak definiować mniejsze grupy procesów według potrzeb.

Kompilacja

W celu skompilowania programu używającego biblioteki MPI musimy stworzyć specjalny, przystosowany do równoległości program binarny. Służą do tego zazwyczaj nakładki na kompilatory mpif77, mpif90, mpicc oraz mpicxx. Parametry do tych nakładek podajemy dokładnie tak samo, jak do kompilatorów.

Uruchamianie

Uruchamianie programu równoległego następuje zazwyczaj poprzez program mpirun. Najczęściej wywołanie ma postać:

mpirun -np N program.x

gdzie N określa liczbę równoległych procesów.

Dostępność w ICM

MPI jest dostępne na wszystkich klastrach oraz superkomputerach w ICM.

W przypadku tornado (Cray X1e) kompilacja programów MPI jest wykonywana przy użyciu standardowych kompilatorów, bez konieczności używania nakładek.

Na halo (klaster Opteron) dostępnych jest kilka wersji MPI, różniących się trybem działania (32/64 bitowe) oraz wykorzystywanymi kompilatorami (GNU/PGI). W zależności od potrzeb należy użyć jednego z poleceń konfigurujących środowisko: use_mpich_gnu32, use_mpich_gnu64, use_mpich_pgi32, use_mpich_pgi52_32, use_mpich_pgi52_64, use_mpich_pgi60_32, use_mpich_pgi60_64, use_mpich_pgi64. Do uruchamiania programów równoległych w systemie kolejkowym służy, w miejsce mpirun, program mpiexec.

Dostępne implementacje

Poza implementacjami związanymi z konkretnymi platformami sprzętowymi, często komercyjnymi, dostępne są dwie popularne, darmowe implementacje MPI: MPICH (http://www-unix.mcs.anl.gov/mpi/mpich/) oraz LAM MPI (http://www.lam-mpi.org/). Ich instalacja na własnym komputerze nie powinna nastręczać poważnych trudności (możliwe jest uruchamianie, w celach testowych, programów równoległych na jednym procesorze).

Dalsze informacje


Maszyny: cpes.icm.edu.pl (kompilacja na tornado)

Autor: Łukasz Bolikowski

Ten krótki artykulik przeznaczony jest dla osób korzystających z komputera tornado (Cray X1e), które intensywnie korzystają z kompilatorów (np. pisząc swoje programy i regularnie je kompilując w poszukiwaniu błędów). Pokażę sposób, dzięki któremu można uzyskać kilkukrotne skrócenie czasu kompilacji. Zacznę od wyjaśnienia "tradycyjnego" mechanizmu kompilacji na tornado, a następnie pokażę, co można usprawnić.

Tradycyjna kompilacja na tornado.icm.edu.pl

Użytkownicy kompilujący programy na tornado wiedzą, że kompilować można jedynie pliki znajdujące się w katalogu /cpes. Ten nakaz bierze się stąd, że kompilacja odbywa sie tak naprawdę na innej maszynie, która "widzi" jedynie katalog /cpes. Ta maszyna nazywa się Cray Programming Environment Server (CPES), stąd nazwa wspólnego katalogu.

Uruchomienie polecenia ftn czy cc na tornado powoduje połączenie z CPES i uruchomienie tam kompilacji, a następnie przekazanie rezultatu z powrotem do programu wywołującego na tornado. Gdy kompilujemy pakiet kilkuset plików, narzut na komunikację pomiędzy tornado a CPES staje się znaczący.

"Chciałoby się" móc zalogować bezpośrednio na CPES i bezpośrednio tam uruchomić kompilację, ale niestety jest to niemożliwe: z punktu widzenia użytkownika ta maszyna nie istnieje, jest "schowana" za tornado. Jedynym śladem istnienia CPES jest (inaczej niezrozumiała) konieczność kompilowania programów wyłącznie w katalogu /cpes.

Pomysł z wykonywaniem pełnej kompilacji kodu na innej maszynie można zrealizować przy pomocy linuksowych wersji kompilatorów Cray.

Cross-kompilacja na cpes.icm.edu.pl

W celu skrócenia czasu kompilacji uruchomiliśmy w ICM komputer o nazwie cpes.icm.edu.pl, działający pod GNU/Linux, na którym zainstalowaliśmy kompilatory Cray. Jest tam zamontowany katalog /cpes z tornado. Podobnie jak na tornado, jest polecenie module pozwalające żonglować wersjami kompilatorów. Oprócz kompilatorów są też biblioteki niezbędne do zbudowania pliku wykonywalnego (craylibs, libsci, mpt).

Każdy użytkownik mający dostęp do tornado ma automatycznie dostęp do cpes.icm.edu.pl, logujemy się tam tradycyjnie przy pomocy ssh. Komputer znajduje się, podobnie jak tornado, w środku sieci ICM, więc chcąc pracować z zewnątrz należy najpierw zalogować się do ICM (gw.icm.edu.pl, atol.icm.edu.pl).

Proszę zwrócić uwagę na kilka faktów:

  • kod, który jest kompilowany na cpes.icm.edu.pl może być wykonany tylko na tornado (a nie na cpes.icm.edu.pl!) - dlatego mówimy, że jest to cross-kompilacja.
  • biblioteki i kompilatory na cpes.icm.edu.pl są pod względem funkcjonalności identyczne jak odpowiadające im pakiety na tornado. Na przykład, polecenie ftn na tornado i ftn na cpes.icm.edu.pl wygenerują identyczny kod wykonywalny.
  • proszę pamiętać, że środowisko programistyczne na Cray X1e jest dosyć często aktualizowane, niezależnie na tornado i na cpes.icm.edu.pl, więc w danym momencie na tornado może być domyślnie używana inna wersja biblioteki niż na cpes.icm.edu.pl. Różnice są jednak kosmetyczne, np. w danej chwili na tornado jest domyślnie używana biblioteka craylibs w wersji 5.4.0.1, a na cpes.icm.edu.pl ta sama biblioteka jest używana w wersji 5.4.0.2.
  • w założeniach administratorów, na cpes.icm.edu.pl mają się pojawiać najnowsze wersje kompilatorów i bibliotek, natomiast na tornado zmiany mają być dokonywane rzadziej (w trosce o stabilną pracę użytkowników).
  • proszę pamiętać, że na Cray X1e wszystkie biblioteki są linkowane statycznie, a więc kod skompilowany i zlinkowany na cpes.icm.edu.pl będzie korzystał z takich bibliotek, jakie były na cpes.icm.edu.pl w momencie kompilacji, a nie z tych, które są na tornado w momencie uruchamiania.
  • cpes.icm.edu.pl ma silniejsze procesory niż CPES (AMD Opteron vs słabsze procesory Sun), co w połączeniu z uproszczeniem kompilacji powoduje, że kod na cpes.icm.edu.pl kompiluje się kilka razy szybciej niż na tornado (a de facto na CPES).

Kiedy nie da się wykorzystać cpes.icm.edu.pl

Jak każde rozwiązanie, cross-kompilacja na cpes.icm.edu.pl ma swoje ograniczenia. Niestety cross-kompilacja nie zadziała gdy chcemy wbudować w kod mechanizmy mierzące wydajność (tzw. instrumented code). Na cpes.icm.edu.pl nie ma polecenia pat_build. Nie można też wykonać kompilacji w stylu:

 ./configure
 make
 make install

gdyż skrypty configure zazwyczaj kompilują i uruchamiają małe programiki w celu sprawdzenia, na jakim systemie pracują.

Dlaczego tak dziwna kompilacja?

Można zadać pytanie: dlaczego firma Cray zdecydowała się na wprowadzienie tak dziwnego sposobu kompilacji? Otóż po pierwsze, procesory wektorowe nie nadają się za bardzo do kompilacji, która jest typowo skalarnym zadaniem. Po drugie, nawet gdyby procesory wektorowe radziły sobie z kompilacją, wykorzystywanie ich do tego typu zadań byłoby pewnym marnotrawstwem: w końcu podstawowym zadaniem tornado jest wykonywanie "ciężkich" obliczeń, a nie kompilacja, która może z powodzeniem być realizowana na dowolnym komputerze.

Podsumowanie

Zachęcam do korzystania z cpes.icm.edu.pl, to stabilny i szybki komputer. Kilku użytkowników ICM kompilujących duże kody bardzo się do niej przekonało.


Porady: Polecenie module

Autor: Maciek Cytowski

Polecenie module służy do zmiany ustawień środowiska programistycznego w systemach operacyjnych UNICOS firmy Cray. W ICM jest ono obecne na maszynach tornado, tajfun, ale także na linuksowym serwerze cpes, na którym zainstalowany jest emulator środowiska programistycznego komputera CrayX1e (więcej o serwerze cpes w sąsiednim artykule).

Organizacja środowiska programistycznego w systemach UNICOS

Ustawienia środowiska programistycznego w systemach UNICOS zorganizowane są w paczkach (modułach). Zawartość każdej takiej paczki definiowana jest w plikach modułowych (z ang. modulefiles) poprzez określenie ścieżek do bibliotek, kompilatorów, programów narzędziowych, stron manuali itd. Polecenie module służy do interpretowania informacji zawartej w takich plikach. Dzięki niemu możemy przeglądać listę obecnie załadowanych modułów, ale również ładować nowe moduły lub podmieniać te już załadowane.

Bardzo ważną funkcjonalnością polecenia module jest możliwość podmiany kompilatorów lub bibliotek na te o starszej wersji. Na komputerach obliczeniowych w ICM domyślnie ładowane są aktualnie najnowsze wersje kompilatorów dostarczane przez firmę Cray. Podmiana domyślnych modułów może być powodem różnic w wykonywaniu i kompilacji naszego kodu na komputerze Cray. Może się okazać, że optymalizacje zaprojektowane w nowym kompilatorze przyśpieszą nasz kod. Może się niestety również okazać, że go spowolnią, bo np. optymalizacja naszego kodu nie chce się "pogodzić" z nowymi kompilatorami. Możliwe jest również, że nasz kod wogóle nie będzie chciał się kompilować (wówczas najlepiej wysłać swój problem na adres: pomoc@icm.edu.pl).

W naszej pracy z komputerem Cray X1e zetknęliśmy się kilkakrotnie z takim problemem, że po aktualizacji jakiejś biblioteki lub kompilatora program przestaje się kompilować lub działa inaczej niż poprzednio. Może to świadczyć o jakimś błędzie w naszym kodzie, który był tolerowany (lub niezauważany) przez poprzednie wersje kompilatorów, a teraz już nie jest. Może to być również spowodowane błędem w nowym kompilatorze czy bibliotece.

Przykład z ostatnich dni dotyczy znacznego spadku wydajności pewnej aplikacji po przekompilowaniu w uaktualnionym środowisku programistycznym. Szukając przyczyny takiego zachowania zmienialiśmy wersje pakietów środowiska programistycznego sprawdzając, które zmiany wpływają na wydajność. Dość szybko ustaliliśmy, że problem dotyczy odwołań do biblioteki mpt, co pozwala zawęzić obszar poszukiwań błędu (choć nadal nie wiemy, czy jest to wina kodu, czy biblioteki).

Jak używać polecenia module?

Oto sposoby użycia polecenia module:

  • module list - wypisuje listę obecnie załadowanych modułów użytkownika
  • module avail - wypisuje listę wszystkich dostępnych modułów (m.in. wszystkie dostępne wersje kompilatorów)
  • module load [modulefile ...] - ładuje moduł o nazwie modulefile
  • module unload [modulefile ...] - usuwa moduł
  • module swap oldmodule newmodule - podmienia moduł oldmodule na moduł newmodule
  • module help [modulefile ...] - wyświetla informację na temat modułu (czasem niestety niewystarczającą, więcej można odnaleźć po załadowaniu modułu i odwiedzeniu odpowiedniej strony manuala)
  • module display [modulefile ...] - wyświetla zawartość danego modułu (zwykle są to komendy ustawiające zmienne środowiskowe)

Następujący prosty przykład pokazuje w jakich sytuacjach używać polecenia module:

Załóżmy, że chcemy sprawdzić czy na komputerze tornado znajdują się jakieś specjalistyczne biblioteki bioinformatyczne, których moglibyśmy użyć w naszym programie. Szczególnie zależy nam na algorytmie Smith-Waterman. Wykonujemy wówczas nastepujące kroki:

1. Sprawdzamy listę aktualnie załadowanych modułów:

user@tornado:/home/users/user# module list
Currently Loaded Modulefiles:
  1) modules     3) totalview   5) craytools   7) mpt         9) libsci     11) PrgEnv     13) open
  2) X11         4) cal         6) cftn        8) CC         10) craylibs   12) pbs

2. Sprawdzamy listę aktualnie dostępnych do załadowania modułów:

user@tornado:/home/users/user# module avail

W wyniku otrzymujemy m.in. listę modułów ładowanych z plików znajdujących się w katalogu: /opt/PE/modulefiles (PE jak Programing Environment). Wśród nich odnajdujemy moduł o nazwie biolib w kilku wersjach:

 biolib              
 biolib.2.0.0.0
 biolib.2.1.0.0
 biolib.2.2.0.0
 biolib.2.3.0.0

Moduł bez numeru wersji to zwykle najnowszy dostępny moduł.

3. Wyświetlamy sobie informację o danym module:

user@tornado:/home/users/user# module help biolib

----------- Module Specific Help for 'biolib' ---------------------

The biolib modulefile defines the default system paths and
environment variables used to access libraries and includes.

Ta informacja nam jednak nie wystarcza. Mówi nam mało, a w szczególności nie mówi nic o algorytmie którego szukamy.

4. Ładujemy najnowszy moduł biolib:

user@tornado:/home/users/user# module load biolib

5. Teraz możemy już przeszukiwać strony manuala modułu biolib. Każde z poniższych wywołań:

user@tornado:/home/users/user# apropos biolib
..
user@tornado:/home/users/user# apropos smith-waterman

wskaże nam interesujące dla nas strony manuala.

6. Gdy zechcemy zmienić wersję danej biblioteki na starszą, wystarczy wpisać np.:

user@tornado:/home/users/user# module swap biolib biolib.2.1.0.0

Hierarchia i przeznaczenie modułów

Wśród modułów istnieje pewna hierarchia. Niektóre z modułów są zgrupowane w jedną dużą paczkę o nazwie PrgEnv. Nie widać tego po uruchomieniu polecenia module list. Wystarczy jednak wypisać informacje o module PrgEnv (module help PrgEnv), by zobaczyć, iż grupuje on w sobie 9 mniejszych modułów ( X11, totalview, cal, craytools, cftn, mpt, CC, libsci, craylibs). Moduł ten ładowany jest zaraz po zalogowaniu na serwer obliczeniowy (zawiera wszystkie najpotrzebniejsze składniki środowiska programistycznego Cray'a). Istnieje możliwość podmieniania wersji pojedynczych komponentów modułu PrgEnv (np. module swap libsci libsci.5.3.0.0). Można również podmienić wersje całego modułu PrgEnv (np. module swap PrgEnv PrgEnv.54.first_set). Nie można jednak usunąć żadnego modułu składowego osobno.

Oto krótki opis dotyczączący przeznaczenia niektórych modułów dostępnych na tornado:

  • mpt - Message Passing Toolkit - zmienne środowiskowe niezbędne dla programowania równoległego (zarówno message passing jak i shared-memory)
  • libsci - Scientific Library - m.in. FFT, BLAS, BLACS, LAPACK, ScaLAPACK
  • craytools - narzędzia Cray'a, m.in. narzędzia do profilingu CrayPAT (Performance Analysis Tool)
  • biolib - bibliotyka bioinformatyczna Cray'a
  • totalview - ustawienie ścieżek dla debugera TotalView (służącego do debugowania programów równoległych)
  • CC - ustawia ścieżki i zmienne środowiskowe niezbędne do korzystania z Cray'owego kompilatora C++

Przydatne linki

W przykładzie korzystania z polecenia module, zawartym w tym artykule, mieliśmy szczęście. Szukaliśmy biblioteki bioinformatycznej i w liście dostępnych modułów odnaleźliśmy moduł o wiele mówiącym przedrostku bio-. W ogólnym przypadku nie bedzie nam tak łatwo. Warto pamiętać jednak, że na WWW dostępna jest obszerna dokumentacja środowiska programistycznego na komputerach Cray: CrayDoc

Obliczenia równoległe przy użyciu Fluent

Autor: Ania Trykozko

Program FLUENT, przeznaczony do symulowania przepływów, umożliwia obliczenia w trybie równoległym. Równoległość jest realizowana w oparciu o podział obszaru obliczeniowego na podobszary. Obliczenia związane z każdym podobszarem są wykonywane niezależnie (równolegle) na procesorach przydzielonych do realizacji zadania. Oczywiście niezbędna jest wymiana informacji między procesorami w celu "uzgodnienia" wartości rozwiązań na stykających się ze sobą brzegach podobszarów.

Podział obszaru powinien spełniać trzy warunki:

  • Liczba komórek w podobszarach powinna być w miarę równa;
  • Podział powinien minimalizować liczbę wspólnych dla podobszarów ścianek komórek (bądź krawędzi, w przypadku 2D);
  • Liczba sąsiadów każdego obszaru powinna być jak najmniejsza.

Jakość podziału można ocenić na podstawie wartości kilku wskaźników generowanych przez program Fluent po dokonaniu podziału. W szczególności Cell count podaje minimalną i maksymalną liczbę komórek w podobszarach, zaś Partition boundary face count to minimalna i maksymalna liczba ścianek sąsiadujących ze ściankami innych podobszarów. Celem jest osiągnięcie możliwie małych wartości wskaźników Partition boundary face count ration oraz Partition boundary cell count ratio przy zachowaniu możliwie równego obciążenia, czyli równej liczby komórek w podobszarach (Mean cell count deviation). Optymalny podział obszaru jest ściśle związany z jego kształtem oraz pokrywającą go siatką dyskretyzacji i dlatego dobrze jest wypróbować różne metody i wybrać najlepszą.

Podział obszaru może zostać wykonany automatycznie (Parallel, Auto Partition) podczas działania Fluenta w trybie równoległym - lub też może zostać wykonany "ręcznie" we Fluencie działającycm w trybie sekwencyjnym lub równoległym, poprzez wydanie polecenia Parallel, Partition i odpowiednie ustawienie opcji. Informacja o dokonanym podziale obszaru zapisana w pliku .cas może zostać wykorzystana w kolejnych obliczeniach.

Bez względu na sposób dokonania podziału (automatyczny lub "ręczny"), zestaw dostępnych metod podziału jest taki sam. Metody podziału to różne warianty bisekcji oraz metoda METIS.

Bisekcja. Metoda bisekcji polega na dzieleniu obszaru "na pół", przy czym proces jest powtarzany tak długo, aż w wyniku kolejnych podziałów powstanie liczba podobszarów odpowiadająca liczbie procesorów. Na przykład, aby podzielić obszar obliczeniowy na 4 części, program najpierw podzieli cały obszar na dwie części, a następnie każdą z części ponownie podzieli na pół. Aby podzielić obszar na trzy części, w pierwszym kroku zostanie on podzieli na dwie części, z ktorych jedna będzie w przybliżeniu dwa razy większa od drugiej, a następnie podzieli większą część na dwie. W ten sposób powstaną trzy podobszary. Kierunek przeprowadzania bisekcji zależy od wybranego schematu i przebiega np. zgodnie w układem współrzędnych (Cartesian Axes), zgodnie z osiami głównymi (Principal Axes), zgodnie z wybraną współrzędną (np. Cartesian Y-coordinate), itd.

Metis. Metoda bisekcji "nie widzi" kształtu obszaru i dlatego w przypadku podziału obszarów o złożonej geometrii najlepsze wyniki osiąga się stosując metodę Metis, bazującą na algorytmie podziału nieregularnych grafów. Metoda ta jako jedyna z dostępnych we Fluencie uwzględnia kształt obszaru podczas dokonywania podziału.

Grafika:metis4.jpg Grafika:cartesian4.jpg Grafika:principal4.jpg
Metis Cartesian Axes Principal Axes

Uruchamianie zadań równoległych w ICM

W ICM obliczenia w trybie równoległym z wykorzystaniem programu FLUENT mogą być wykonywane na klastrze "halo".

Etapy uruchamiania obliczeń w trybie równoległym:

  • Podział obszaru obliczeniowego (na podstawie pliku .cas lub pliku z siatką).
  • Uruchomienie Fluenta w wersji równoległej.

Zmiany w skrypcie kolejkowym, w porównaniu ze skryptem dla obliczeń w wersji sekwencyjnej są następujące:

1. zdefiniowanie liczby procesorów, np. polecenie:

#PBS -l nodes=2:ppn=2

oznacza dwa węzły (nodes=2), na każdym dwa procesory (ppn=2); w sumie 4 procesory.

2. zdefiniowanie pliku (o przykładowej nazwie hostfile), w którym znajdą się nazwy maszyn przydzielonych przez system kolejkowy do realizacji zadania:

 cat $PBS_NODEFILE > hostfile

Plik ten należy podać jako jeden z parametrów w wywołaniu programu Fluent.

3. podanie dodatkowych parametrów w wywołaniu programu:

 fluent 3ddp -pnmpi -t4 -cnf=hostfile -g -i inputfile > output
  • -pnmpi określa sposób komunikacji między węzłami,
  • -t4 określa liczbę procesorów (tu: 4),
  • -cnf=hostfile wskazuje na plik, w którym zapisane są nazwy maszyn, na których będą wykonywane obliczenia.

W przypadku wykonywania obliczeń na dwóch procesorach na tym samym węźle (ustawienie: #PBS -l nodes=1:ppn=2) nie ma potrzeby definowania pliku hostfile, zaś polecenie uruchamiające program Fluent ma postać:

 fluent 3d -t2 -g -i inputfile > output

Szczegółowe omówienie skryptu kolejkowego znajduje się na stronie: http://www.icm.edu.pl/kdm/programy/fluent/obliczenia/kolejka_par.php

Na zakończenie...

W ogólnym przypadku czas obliczeń ulega skróceniu w miarę wzrostu liczby procesorów. Jednak większa liczba procesorów wykorzystanych w obliczeniach zwiększa równocześnie czas potrzebny do komunikacji między procesorami. Dlatego też liczba procesorów powinna być dopasowana do rozmiaru i rodzaju zadania.

Linki

Wydarzenia: Szkolenie Fluent

Autor: Ania Trykozko

W dniu 7 października 2005 odbyło się szkolenie KDM dotyczące programu Fluent. Szkolenie przeprowadził przedstawiciel firmy Fluent w Polsce dr Leszek Rudniak z firmy SymKom. Podczas szkolenia omowiono implementację metody objętości skończonych w programie Fluent oraz przedyskutowano wpływ jakości, topologii oraz gęstości siatki obliczeniowej na dokładność uzyskanych wynikow. Przedstawiono rownież nowe algorytmy oraz schematy dyskretyzacji, ktore pojawily sie w wersji 6.2 Fluenta. Warto wspomnieć, że kolejna, oznaczona numerem 6.3, wersja Fluenta pojawi się w pierwszym kwartale 2006 roku.

Szkolenie spotkało się z bardzo dużym zainteresowaniem. Dlatego z przyjemnością informujemy, że na stronie KDM znajdują się materiały ze szkolenia.