CC BY
41
Dr hab. inz. Tadeusz MACIAK mgr inz. Przemyslaw CZAJKOWSKI
Wydzial Informatyki Politechniki Bialostockiej
FDS. ANALIZA PROCESU OBLICZENIOWEGO SYMULACJI POZARU W TUNELU1
FDS. Analysis of the computational simulation of fire in the tunnel.
Streszczenie
W pracy, na przykladzie przeprowadzonej symulacji pozaru, porownano czasy obliczen otrzymane z uzyciem roznej ilosci rdzeni mikroprocesora. Rozwazany przypadek dotyczyl jednej nitki tunelu samochodowego o dlugosci 4000 m. Zrodlem ognia byla cysterna z benzyn^ dla ktorej zalozono moc zrodla ognia 100 kW. Obliczenia dotyczyly szybkosci rozprzestrze-niania si§ pozaru i badania skutecznosci dzialania roznych rozwi^zan wentylacji. Otrzymane przebiegi wielkosci fizycznych typu temperatura, czy st^zenie niebezpiecznych gazow mialy drugorz^dne znaczenie i nie byly poddawane analizie oraz weryfikacji. Istotnym z punktu widzenia pracy byl natomiast czas wykonania symulacji oraz przyspieszenie uzyskane przez zastosowanie wielu komputerow do obliczen. Obliczenia zostaly wykonane dla 4 przypadkow: a/ staly rozmiar zadania do wykonania, rosn^ca liczba procesow wykomjcych te same zadanie, b/ staly rozmiar zadania do wykonania, rozne liczby w^tkow wykonuj^cych obliczenia, c/ rosn^cy rozmiar zadania obliczeniowego, rosn^ca liczba procesorow wykonuj^cych zadanie, d/ rosn^cy rozmiar zadania obliczeniowego, rosn^ca liczba w^tkow wykonuj^cych obliczenia. Do oceny otrzyma-nych czasow wykonania roznych przypadkow symulacji zastosowano miary przyspieszenia obliczen przy stalej wielkosci zadania, wzrostu wydajnosci systemu przy stalej wielkosci zadania oraz wzrostu wydajnosci systemu przy rosn^cej wielkosci zadania. W analizowanym przypadku przestrzen symulacji zostala podzielona na n domen obliczeniowych wzdluz osi najdluzszego boku tunelu. Obliczenia dla jednej domeny obliczeniowej zostaly wykonane przez wej szeregow^. FDS, ktora korzystala z jednego rdzenia procesora. W przypadkach z liczby domen obliczeniowych wi^ksz^. od jednosci, obliczenia zostaly wykonane przez wej rownolegl^. FDS i uzywaly roznej liczby rdzeni. Dla kazdej z domen obliczeniowych, obliczenia przeprowadzal osobny proces. Kazdy z procesow byl przydzielony do osobnego rdzenia procesora. Do komunika-cji mi^dzy procesami wykorzystano mechanizm Message Passing Interface (MPI), ktory organizowal komputer w logiczn^. maszyn§ z pami^ci^. rozproszon^. Odmiana FDS ograniczaj^ca si§ do wykorzystania do obliczen wielu rdzeni tego samego procesora zostala napisana przy uzyciu dyrektyw OpenMP, natomiast wersja rownolegla, ktora do obliczen moze uzywac zarowno komputerow pol^czonych w siec, jak i wielu rdzeni jednego procesora korzysta z wywolan funkcji MPI. Wyniki przeprowadzonych eksperymentow numerycznych pokazaly, ze oba uzyte mechanizmy przyspieszaj^. obliczenia symulacji w stosunku do wykonania przez jeden rdzen procesora choc nie w sposob liniowy. Czasy wykonania symulacji przez wersja OpenMP byly znacz^co wyzsze niz MPI. Przebadano rowniez skalowalnosc systemu rozumianego jako komputer oraz program. Rowniez i w tym przypadku otrzymane wyniki wykazaly, ze lepiej zachowuje si§ wersja MPI. Wersja OpenMP okazala si§ nie skalowaln^. w przeprowadzonych eksperymentach. Porownuj^c szybkosci wykonywanych obliczen na pro-cesorach pochodz^cych od dwoch wiod^cych producentow Intela I AMD zauwazono, ze na procesorach Intel symulacje s^. wykonywane zdecydowanie szybciej.
Summary
In this paper, on the chosen example of the simulation of fire, compared the calculation times obtained using different number microprocessor cores. Considered case concerned a thread car tunnel with a length of 4000 m. The source of the fire was a tank of gasoline, which was founded for the fire power of 100 kW. Calculations related to the speed of the spread of the fire and test the effectiveness of various ventilation solutions. The resulting waveforms physical quantities such temperature, and the concentration of dangerous gases were of secondary importance and were not analyzed and verified. Important from the point of view of work execution time was while simulation and acceleration achieved by the use of multiple computers for calculations. The calculations were made for four cases: a / fixed size tasks to be performed, increasing the number of processes performing the same task, b / fixed size tasks to be performed, the number of threads performing various calculations, c / growing magnitude of the task calculation, a growing number of processors that perform the task, d / growing magnitude of the task calculation, a growing number of threads performing calculations. For the evaluation of execution times received different cases of measurement used to accelerate simulation calculations with a constant magnitude of the task, the growth performance of the system with a constant increase in the size of the task and
1 Wklad obu autorow w powstanie artykulu wyniosl po 50%
the system performance by increasing the size of the task. In the present case the simulation space is divided into n computational domain along the longest side of the tunnel. Calculations for a single computational domain were made by the serial version of FDS, whichusedasinglecoreprocessor. In thecaseof computing thenumberofdomains isgreater than unity,the calculation wasperformedbyaparalle l netoooneenge SDSandus ehanSSfeoonhhumbe r o f eores.For eac h of the computational domain, the calculations carried out separate process. Each treatment was assigned to a separate processor core. Forintps-nanoosbhommuuicatinh mefhaihim nsed Msssage PossingenSerfacegMPdtw0^c^S^ orgarbhehegecomputer in a logical distributed memory machine. FDS variant limiting the use of multiple cores for the calculation of the same processor waiesritten osrng OpenMP directives^M1 e parallen versro^whkahcante used to caleuhtel^c^ihtbenelworked comyio^^ryc^^da^i^Snplei^i^re s per procesno r us^e^sl^be IVffl fuhctionc;ais.Therenhts oaiPng^i^s^en^^ee^S'er^n^ent^s shown that both mechanisms speed up the calculation used for the simulation performed by the one processor core, although not in a linear fashion.The ^r^e^ o;^ ^l^s; angulation by the OpenMP version were significantly higher than MPI. We investigated also scalability of the system defined as a computer and software. Also in this case the results show that behaves better version of MPI. OpenMP version turned out to be not scalable in the experiments. Comparing the speed of the processors of the calculation from two leading manufacturers Intel and AMD noted that Intel simulations are performed much faster.
Slowa lduczowe: FDS,modelowamarozwoju pozaru wpomieszczeniach zamkni^tych; Keywords: FDS, modeling the spread of fire in enclosed spaces;
1. Wst$p
Cekm^preedmejjweyauteaow he hylo neprezen-towamehSiorytmhw matemehPongph hinF(^yehi^omoc^^-lowania rozwoju pozaru w pomieszczeniach zamkni^tych. Przenlstawtinyms del ragdi;erujenume-
ryczWe s^^^n pa)gcl r^rneznceenpcni^^e^snenilywph' nieduzej pr^dkosci rownan Navier-Stokes 'a z uwzgl^dnie-niemziawllkapezepihwutie]Da nr^ ^ahnzs^ak.Wt wspommpgnmoDygge ^roconorop^n^i^eien\^agr oaoe;ra-niczenia i uproszczenia w opisanych modelach. W bwbcrjggnri]racii.naprwlgSaClic rymurhej° ^ozstr w tunslu,har6wn;mo c^^a^r^obll^^^nc^t^^ mwrew weti padkach wykonania symulacji przez komputer z proce-soremwieUardne niowym, z uzyciem roznej ilosci rdzeni do obliczen oraz \wkorgmalhmiracjipsaeejedenrPzeri. Artykul powstal na podstawie eksperymentow numerycz-nych, przeprowadzonych w ramach pracy [2] z wykorzy-staniemnpro[h"amownhih F^iF/ye Dyn op/'ceSimalotoe) [3].
..Zainzeina eks.caymentu numerycznego
2h. PenedmihilhhПllhatl
Przypadek zrealizowanej symulacji pozaru, do ba-damo zachowwlihiieo^hiczerihrowadzhnpehr6wnole-jle prcn nnyeiu wlelu prncescrow, eoslal z^ckrpni^ty z pracy [4]. W zapozyczonym przykladzie obliczenia dohrniyfys.ymdaciiroz^aesSrzeniania r^ pozaru i ba-daaie rozpychrazwlanah wentpraniiisrt skuarrznosci. W przypadku przeprowadzonych w ramach niniejszej piacysymulnrriotrzymane .roda^. wif.ofoi fizycz-nnch tyhp SewperoSnta, eoc 81^6106 hiebezpiecznych ga-zow maj^ drugorz^dne znaczenie i nie byly poddawane analizie i weryfikacji. Istotnym z punktu widzenia pracy byigaeeпuaatrnnswnnonanio spmylocji orazprzyspie-ssenoeuzy spine prencoastosiw;wie wiehi komputerow do obliczen. St^d tez, do rozwazan zostal wybrany jeden prehb1odomnprzrlpadnyprcprjreemsymuracj i.
Ryc. 1. Wymiary tunelu dla rozpatrywanego przypadku symulacji wg. [4] Fig. 1. Tunnel dimension for fire simulation cases, according to [4].
Rozwazany przypadek dotyczy jednej nitki tunelu sa-mochodowego o dlugosci 4000 m. Z powodu na znaczne wymiary badanego obiektu i nie znaczny wplyw pozaru na przestrzen znaczenie oddalone od zrodla ognia, autorzy opracowania [4], zdecydowali siç na zmniejszenie symu-lowanej przestrzeni do 550 m. Schematyczny uklad symu-lowanej przestrzeni przedstawia rysunek 1.
Zrodlem ognia byla cysterna z benzyne, dla ktorej zalozono moc zrodla ognia 100 kW. Zrodlo ognia zosta-lo umieszczone 1800 m od wjazdu do tunelu, a 200 m od poczetku przestrzeni objçtej symulacje. Wymiary przekroju poprzecznego przestrzeni przeznaczonej na ruch pojazdow wynosily odpowiednio 9,75 m szerokosci i 4.7 m wysoko-sci. Ponad jezdnie znajdowal siç szyb wentylacyjny nad cale szerokoscie i dlugoscie tunelu o wymiarach 9,75 x 1.8 m. Wymiary przekroju tunelu przedstawiono na rysunku 2.
A A
/ / / /
/ n a 1 wentytacyjny /
/ /
/ 3/
oluor wentylacyjny /
/
pi 1 /га ]'(■ г h и [>'i j.i /
71 Г
/ / S / /
9,75
Ryc. 2. Przekroj rozwazanego tunelu, wg. [4].
Fig. 2. Cross section of the tunnel under consideration, according to [4].
Na zakonczeniach kanalu wentylacyjnego znajdowaly siç dwa wentylatory wyciegajece powietrze. Zalozono, ze ich wydajnosc wynosila po 160 m3/s na dwoch koncach kanalu wentylacyjnego. Dodatkowo, przez wejscie do tunelu dostawal siç do przestrzeni symulacji strumien swiezego powietrza o szybkosci przeplywu148 m3/s . Na koncach tunelu cisnienie zostalo ustalone na poziomie domyslnego cisnienia atmosferycznego ( 101 325 Pa ). Otwor leczecy kanal wentylacyjny z przestrzeni^. ruchu zostal usytuowa-ny 35 m od zrodla ognia. Wymiary wspomnianego otwo-ru wynosily 8 m x 3 m. Zalozono, ze sciany tunelu maje
grubosc 0,5 m i se wykonane z betonu o wlasciwosciach podanych w tabeli 1.
2.2. Zalo/enia obliczeniowe
Obliczenia dla przedstawionego zdarzenia pozaru w tunelu zostaly wykonane dla 4 przypadkow:
a. staly rozmiar zadania do wykonania, rosneca liczba procesow wykonujecych te same zadanie;
b. staly rozmiar zadania do wykonania, rozne liczby wetkow wykonujecych obliczenia;
c. rosnecy rozmiar zadania obliczeniowego, rosneca liczba procesorow wykonujecych zadanie;
d. rosnecy rozmiar zadania obliczeniowego, rosneca liczba wetkow wykonujecych obliczenia.
Do oceny otrzymanych czasow wykonania roznych przypadkow symulacji zastosowano 3 miary: przyspie-szenie obliczen przy stalej wielkosci zadania, wydajnosc systemu przy stalej wielkosci zadania oraz wydajnosc sy-stemu przy rosnecej wielkosci zadania.
2.2.1. Okreslenieprzyspieszenia obliczen wykonywa-nych w sposob rownolegfy
Przyspieszenie dla obliczen wykonywanych rownolegle okreslono zgodnie ze wzorem:
S(p) = T(1)/T(p) (1)
Gdzie:
T(1) - czas obliczen, przy podziale przestrzeni symulacji na jedne domenç obliczeniowe wykonywanych przez wersjç szeregowe oprogramowania FDS, T(p) - czas obliczen, przy podziale na wiçcej niz jedne do-menç obliczeniowe, wykonywanych przez wersjç rownolegle oprogramowania FDS, p - liczba procesorow wykonujecych obliczenia row-nolegle.
Idealnym przyspieszeniem jest S(p) = p - (przyspie-szenie liniowe).
2.2.2. Okreslenie wydajnosci systemu przy stafym rozmiarze zadania
Wydajnosc systemu jest ilorazem osiegniçtego przyspieszenia do idealnego przyspieszenia liniowego. Okresla je wzor:
(p) = S(p)/p = T(1)/pT(p) (2)
Gdzie:
S(p) - przyspieszenie okreslone wzorem (1),
Tabela 1.
Wlasciwosci materialu uzytego do konstrukcji scian tunelu, zrodlo: [4].
Table 1.
Properties of the material used to construct the tunnel wall, source: [4].
gçstosc (density) 2280 kg/m3
cieplo wlasciwe (specific heat) 1,04 kJ/kgK
przewodnictwo cieplne (thermal conductivity) 1,8 W/mK
emisyjnosc (emissivity) 0,9
wspôlczynnik absorpcji (absorption coefficient) 5-1041/m
p - liczba procesorow wykonuj^cych obliczenia row-nolegle.
2.2.3. Okreslenie wydajnosc systemu przy rosnqcym rozmiarze zadania
Wydajnosc systemu, b^d^ca funkj dwoch zmiennych: liczby procesorow oraz wielkosci zadania, zostala okre-slona wzorem:
E(n,p) = T(n,1)/pT(n,p) (3)
Gdzie:
n - wzgl^dny rozmiar zadania w stosunku do naj-mniejszego zadania uzytego w porownaniu; dla najmniejszego zadania n = 1, p - liczba procesorow wykonuj^cych obliczenia, T(n,1) - czas wykonania zadania o rozmiarze n przez wer-
sj§ szeregow^ FDS, T(n,p) - czas wykonania zadania o rozmiarze n przez p procesorow prze wersj§ rownolegl^ FDS.
2.3 Parametry stacji obliczeniowej
Eksperyment numeryczny zostal przeprowadzony na komputerze, ktorego podstawowe parametry przedstawia tabela 2. Obliczenia powtarzano 3 krotnie dla kazdego z przypadkow.
Tabela 2.
Parametry komputera uzytego do przeprowadzenia eksperymentu numerycznego
Table 2
The parameters used to carry out computer numerical experiment
3. Wyniki eksperymentu numerycznego 3.1. Stala wielkosc zadania, rosn^ca liczba procesorow
W analizowanym przypadku przestrzen symulacji zostala podzielona na n ( od 1 do 4 ) domen obliczeniowych wzdluz osi najdluzszego boku tunelu. Podzial przestrzeni symulacji przedstawia rysunek 3.
Kazda z domen obliczeniowych zostala podzielona na
tak^. sam^. liczby komórek o rozmiarach ok. 0,69 m x 0,67 m x 0,67 m kazda. Liczby komórek przypadaj^cych na jcdn;| domcnp obliczeniow^ przedstawia tabela 3.
(n-l)-sza domeña
obliczeniowa , i=0 -\ i=n-l
i"....................^k
550 m
Ryc. 3. Podzial przestrzeni symulacji na domeny obliczeniowe.
Fig. 3. Division of the computational domain simulation.
Tabela 3.
Liczba komorek przypadaj^cych na domeny obliczeniowe
Table 3
Number of cells per computational domain
Liczba domen (Number of domains) Liczba komórek w domenie (The number of cells in the domain) Liczba wszystkich komórek (The total number of cells)
1 152 256 152 256
2 76 128 152 256
3 50 688 152 064
4 38 064 152 256
Obliczenia dla jednej domeny obliczeniowej zostaly wykonane przez wej szeregow^. FDS, która korzystala z jednego rdzenia procesora. W przypadkach z liczby domen obliczeniowych wi^ksz^. od jednosci, obliczenia zostaly wykonane przez wej równolegl^. FDS i uzywaly róznej liczby rdzeni. Dla kazdej z domen obliczeniowych, obliczenia przeprowadzal osobny proces. Kazdy z pro-cesów byl przydzielony do osobnego rdzenia procesora. Przydzielaniem procesów do procesorów zajmowal si§ system operacyjny [5]. Do komunikacji mi^dzy procesa-mi wykorzystano mechanizm Message Passing Interface (MPI) [6], który organizuje komputer w logiczn^. maszyn^ z pami^ci^. rozproszon^, pomimo, ze faktycznie, komputer uzyty do przeprowadzenia eksperymentu byl maszyn^. ze wspóln^ pami^ci^. [7].
Srednie arytmetyczne otrzymanych czasów wykonania symulacji zawiera tabela 4.
Wyznaczone na podstawie wzoru (1) przyspieszenie uzyskane w wyniku dodawania kolejnych procesorów pre-zentuje tabela 4. Otrzymane wyniki dla 2 i 3 procesorów s^. zblizone - wzrost przyspieszenia na kazdy dodatkowy procesor na poziomie ok. 35 - 40% w stosunku do zadania
Parametr (parameter) Wartosc (value)
Typ procesora (Processor type) Intel(R) Core(TM) 2 Quad Q6600
Liczba rdzeni (Number of Cores) 4
Cz^stotliwosc taktowania jednego rdzenia (A core clock speed) 2,4 GHz
Wielkosc pami^ci RAM (Size of the RAM) 4,0 GB
System operacyjny (Operating System) Windows 7, 64-bit
Szczególowe wyniki przeprowadzonych obliczen znajduj^. si§ w pracy [2].
Ryc. 4. Wykres wartosci przyspieszenia obliczen przy stalym rozmiarze zadania obliczeniowego w funkcji liczby procesorow wykomjcych obliczenia. Fig. 4. The graph of acceleration calculations in fixed-size computing task as a function of the number
of processors that perform the calculation.
wykonywanego przez jeden procesor. Jest to takze wynik podobny do wynikow opisywanych w Internecie, na forum uzytkownikow FDS.
Nieco nizszym rezultatem charakteryzuje si§ przypa-dek wykonany przez 4 procesory - wzrost przyspieszenia o okolo 18 % w stosunku do zadania wykonywanego przez jeden procesor. Przyczyne takiego stanu jest to, ze w przy-padku liczby domen, na ktore podzielono przestrzen sy-mulacji, mniejszej od liczby rdzeni procesora, obliczenia dla domen byly wykonywane przez osobne procesy, ktore z kolei przewaznie wykonywaly si§ na roznych rdzeniach procesora, przez co nie konkurowaly ze sobe o przyznanie procesora przez system operacyjny. Wtedy, przynajmniej jeden z rdzeni pozostawal w znacznej mierze nie uzywa-ny do obliczen, zwykle byl wykorzystywany do obslugi innych zadan systemu operacyjnego. W przypadku do-dania 4 domeny, procesy byly wykonywane zwykle na osobnych rdzeniach, ale pojawil si§ problem rywalizacji o czas procesora z innymi zadaniami systemu operacyj-
nego, czego efektem jest mniejszy wzrost przyspieszenia przy wykonaniu obliczen przez 4 rdzenie w stosunku do obliczen wykonanych przez 3 rdzenie.
Porównanie przyspieszenia z przypadkiem idealnym - przyspieszeniem liniowym, prezentuje rysunek 4.
3.1.1. Komunikacja miqdzy procesami
W przypadku podzialu zadania pomi^dzy kilka proce-sorów, poszczególne domeny obliczeniowe musze si§ na-wzajem komunikowac w celu wymiany wartosci wyzna-czanych wielkosci fizycznych przylegajecych granicach. Wymianie podlegaje wielkosci z granicznych komórek obliczeniowych sesiadujecych domen. Czas poswi^cony na komunikacja moze byc odczytany z plików wyjscio-wych otrzymanych w wyniku obliczen. Przy stalym roz-miarze zadania obliczeniowego wraz ze wzrostem liczby domen obliczeniowych, na które dzieli si§ przestrzen sy-mulacji, rosnie liczba komórek, dla których do obliczen se potrzebne wartosci z sesiedniej domeny obliczeniowej.
i=0
(n-l)-sza domeña obliczeniowa
i=n-l
\
\
granica domen obliczeniowych
Ryc. 5. Podzial plaszczyzny na domeny obliczeniowe z zaznaczeniem komorek granicznych w przyleglych domenach obliczeniowych. Fig. 5. The division plane of the computational domain selection border cells in adjacent computing domains
Takie komórki wystçpuj^. na granicach przyleglych domen obliczeniowych. Przyklad takiej sytuacji na plaszczyznie prezentuje rysunek 5, gdzie zaprezentowano podzial pro-stok^tnej plaszczyzny na n czçsci. Kazda z n czçsci jest podzielona na komórki obliczeniowe. Czerwonymi liniami zostaly zaznaczone granice przylegaj^cych domen. Szarym kolorem wypelniono komórki, dla których wyma-gana jest wymiana informacji z komórkami z s^siedniej domeny.
W przypadku przeprowadzonych eksperymentów nu-merycznych, przestrzen symulacji zostala podzielona na jednakowe domeny obliczeniowe wzdluz najdluzszego boku tunelu tak, jak jest to przedstawione na rysunku З. Zastosowano taki podzial ze wzglçdu na redukcjç ilosci komórek, które wymagaj^. komunikacji z s^siedni^. domeny - powierzchnia styku s^siednich domen jest przy takim podziale najmniejsza.
Otrzymany procentowy udzial czasu poswiçcone-go na komunikacjç miçdzy domenami obliczeniowymi w stosunku do calego czasu obliczen w pojedynczej do-menie zostal zestawiony w tabeli 5.
niz w przypadku domeny l.
Inna sytuacja ma miejsce w przypadku obliczen prowadzonych przez З procesory. Tutaj takze wszystkie domeny obliczeniowej obejmuj^. dokladnie takie same rozmiary, z tym, ze dwie domeny: domena l oraz domena З obejmuj^. obszary na obu koncach symulowanego tunelu, domena 2 znajduje siç pomiçdzy nimi, obejmuje ob-szar, gdzie znajduje siç zródlo ognia. Domeny l oraz З nie komunikuj^. siç ze sob^. bezposrednio, a гоЫц. to jedynie z domeny 2. Natomiast domena 2, musi komunikowac siç z dwoma s^siaduj^cymi domenami, czyli dwa razy wiçcej komórek wymaga wymiany informacji niz w domenach l i З. Wyjasnia to, dlaczego pomimo wiçkszego zadania ob-liczeniowego z tytulu obecnosci zródla ognia w domenie 2, procentowo poswiçcony czas na komunikacjç stanowi wiçksz^. czçsc calego czasu obliczen niz w przypadku domen l i З.
Przypadek z czterema procesorami jest przykladem innej sytuacji, gdzie pomimo dokladnie takiej samej liczby s^siaduj^cych komórek w poszczególnych domenach, jak w przypadku З procesorów, procentowe udzialy ko-
Tabela 5.
Procentowy udzial czasu poswiçconego na komunikacjç w poszczegölnych domenach obliczeniowych w stosunku do calego czasu obliczen, przy uzyciu röznej liczby procesöw, dla stalego rozmiaru zadania
Table 5.
Percentage of time spent on communication in various computing domains with respect to the computation time,
with a different number of processes for a fixed size task
Liczba procesorów (Number of processors) Procent caJkowitego czasu obliczen poswi^cony na komunikacje (Percentage of total time spent on communication calculations)
Domena 1 (Domain 1) Domena 2 (Domain 2) Domena 3 (Domain З) Domena 4 (Domain 4)
1 0.00 %
2 0.8б % 0.бб %
3 0.8б % 1.29 % 0.90 %
4 1.2б % 1.8З % 2.10 % 1.ЗЗ %
Procenty czasów poswiçconych na komunikacjç w domenach obliczeniowych rózni^. siç miçdzy sob^. na-wet w obrçbie tego samego przypadku ( w domenach obliczeniowych dla tego samego zadania ). Np. dla przypadku wykonywanego przez 2 procesory czasy poswiçcone na komunikacjç s^. rózne, pomimo tego, ze dwie domeny obejmuje fragmenty przestrzeni symulacji o dokladnie takich samych wymiarach, dokladnie taka sama jest tez ilosc komórek, które wymagaj^. wymiany informacji. Po-wodem takiego stanu jest niesymetryczny charakter po-dzialu przestrzeni symulacji - w jednej z domen znajduje siç zródlo ognia oraz otwór wentylacyjny, co powodujç obecnosc dodatkowych obliczen w tej domenie ponad ob-liczenia wykonywane, w drugiej z domen, gdzie oblicze-nia dotycz^. jedynie przeplywu gazów, rozprzestrzeniania siç ciepla i nagrzewania siç scian tunel. Oznacza to, ze taki sam czas poswiçcony na komunikacjç bçdzie stanowil mniejszy procent calych obliczen w przypadku domeny 2
munikacji miçdzy domenami s^. wiçksze niz wariantu z podzialem na З domeny. Dziejç siç tak, poniewaz domeny obejmuje mniejsze fragmenty przestrzeni symulacji, co oznacza mniejsze zadania obliczeniowe, natomiast ilosc komórek, dla których nalezy wymienic informacje pomiç-dzy domenami jest taka sama.
3.2. Rosn^cy rozmiar zadania, rosn^ca liczbapro-cesorów
Obliczenia przeprowadzono przy uzyciu wersji FDS wykorzystuj^cej wywolania MPI. Scenariusze symulacji zostaly zdefiniowane w ten sposób, ze cala przestrzen symulacji byla dzielona na n ( do l do 4 ) domen obliczeniowych, tak jak zostalo to opisane w punkcie З.1. i przedstawione na rysunku З. Obliczeniami dla jednej domeny zajmowal siç jeden rdzen procesora. Zamiana rozmiaru zadania zostala osi^gniçta przez zmianç rozmiaru komórek, na które byla podzielona domena obliczeniowa. Przy-
j§to, ze zadanie o rozmiarze dwukrotnie wi^kszym b^dzie wtedy, gdy liczba komorek w domenie b^dzie dwukrotnie wi^ksza.
Eksperymenty numeryczne przeprowadzono na kom-puterze, ktorego parametry przedstawiono w tabeli 2. Do obliczen wykorzystano od 2 do 4 procesow, ktore byly przydzielane przez system operacyjny osobnym rdzeniom procesora. Przeprowadzono po 3 proby dla wszystkich rozmiarow zadania obliczeniowego. Punktem odniesie-nia do oceny otrzymanych czasow wykonania symulacji z uzyciem wielu procesorow byly czasy wykonania zadan o takim samym rozmiarze jak zadania wykonywane przez wiele procesorow wykonane przez jeden procesor, przez wej szeregowe FDS. Srednie arytmetyczne otrzymanych czasow wykonania symulacji dla poszczegolnych przypadkow wykonywanych w zaleznosci od liczby procesorow wykonujecych zadanie oraz srednie czasy wykonania tych samych zadan przez wej szeregowe FDS przedstawia tabela 6.
Przeprowadzenie eksperymentu z rosnece wielkos-cie zadania pozwolilo zbadac skalowalnosc systemu. System nalezy rozumiec jako par§: komputer oraz program do symulacji. Otrzymane czasy wykonania poszczegol-nych przypadkow wskazuje na znaczne skrocenie czasu wykonania zadan na kilku procesorach w stosunku do czasu wykonania tych samych zadan przez wersje szeregowe FDS. Otrzymane rezultaty wskazuje na spadek wydajnosci systemu na poziomie do ok. 10% na kazdy dodatkowy proces i jednoczesny wzrost zadania obli-czeniowego dla liczby procesow 2 oraz 3. Dla liczby procesow rownej 4 spadek wydajnosci jest wi^kszy - na poziomie 20%. Przyczyne wi^kszego spadku wydajno-sci dla obliczen wykonywanych na wszystkich rdzeniach procesora jest obecnosc innych zadan w systemie ope-racyjnym, ktore musze byc wykonywane. W przypadku liczby procesow wykonujecych obliczenia mniejszej niz liczba dost^pnych rdzeni w systemie, te inne zadania wykonywane przez system operacyjny byly glownie wy-
Tabela 6.
Czasy wykonania symulacji przy uzyciu roznej liczby procesorow, dla rosn^cego rozmiaru zadania
Table 6.
The time of the simulation using different numbers of processors, the growing size of the task
Liczba procesorow (Number of processors) Liczba komorek (Number of cells) Rozmiary komorek [m] (Cell .size [m]) Czas wykonania (MPI) [sek] (Execution time (MPI) [sec]) Czas wykonania (sze- regowa) [sek] (Execution time (serial) [sec]) Wydajnosc (wg. wzoru 3) (Performance (according to formula 3))
1 40 000 1,1 x 1,08 x 1 3103.2 3103.2 1.0
2 81 900 0,87 x 0,83 x 0,8 3026.2 5328.0 0.88
3 121 110 0,79 x 0,77 x 0,8 3816.0 9540.0 0.833
4 152 256 0,7 x 0,67 x 0,67 4248.0 10790.0 0.635
;--f.-j 1 i—---
_. J..._......
......j............
.......r............. j__________
|
1
2,CO
liczba procesorow
[— MPI — idsaina wydajnosc |
Ryc. 6. Wykres wydajnosci systemu przy rosnecym rozmiarze zadania obliczeniowego od liczby procesorow wykonuje-
cych obliczenia.
Fig. 6 Chart performance of the system with the increasing size of the task calculation of the number of processors that
perform calculations.
konywane na niewykorzystywanym do obliczen rdzeniu procesora, przez co w niewielkim stopniu konkurowaly o przyznanie procesora z procesami wykonuj^cymi ob-liczenia. Otrzymane wydajnosci wyznaczone zgodnie z wzorem (3) prezentuje tabela 6. Porównanie uzyskanej wydajnosci prezentuje wykres 6.
udzial komunikacji rósl wraz ze wzrostem liczby komó-rek. Tak^. sytuacjç na plaszczyznie prezentuje rysunek 7.
W przykladzie 1 z rysunku 7 plaszczyzna zostala po-dzielona na dwie domeny, kazda po 48 komórek. W tym przypadku w domenie 1, wymiany informacji z domeny 2 wymaga 6 komórek ( komórki zaznaczone na szaro ).
Tabela 7.
Procentowy udzial czasu poswiçconego na komunikacjç w poszczegolnych domenach obliczeniowych w stosunku do calego czasu obliczen, przy uzyciu roznej liczby procesow, dla rosn^cego rozmiaru zadania
Table 7.
Percentage of time spent in each domain communication for computing the time of computation, using a number
of different processes for increasing the size of the task
Liczba procesorów (Number of processors) Procent calkowitego czasu obliczen poswiçcony na komunikacje (Percentage of total time spent on communication calculations)
Domena 1 (Domain 1) Domena 2 (Domain 2) Domena 3 (Domain 3) Domena 4 (Domain 4)
1 0.00 %
2 1.32 % 1.67 %
3 1.39 % 2.07 % 1.50 %
4 2.04 % 3.00 % 3.38 % 2.26 %
Przyklad 1
domeña 1
domeña 2
Przyklad 2
domeña 1 domena 2 domena 3 domena 4
Ryc. 7. Podzial plaszczyzn na domeny obliczeniowe z zaznaczeniem komorek. Fig. 7. Division planes on computational domain, indicating the cells.
3.2.1. Komunikacja miçdzy procesami Procentowy udzial czasu poswiçconego na komunikacjç pomiçdzy domenami w stosunku do calego czasu
obliczen w poszczególnych domenach przedstawia tabela 7. Do zjawisk opisanych w punkcie 3.1.1., które takze do-tycz^. eksperymentu z rosn^cym rozmiarem zadania obli-czeniowego, dochodzi jeszcze jedno. W tym przypadku liczba komórek w domenie obliczeniowej byla podobna niezaleznie od liczby procesorów wykonuj^cych zadania. Zostalo to osi^gniçta przez zwiçkszanie liczby komórek w domenie obliczeniowej wraz ze wzrostem liczy procesorów wykomjcych zadanie. Zatem mozna uznac, ze samo zadanie obliczeniowe bylo stale, zmieniala siç natomiast liczba komórek dla których nalezalo wymienic informa-cjç z s^siednimi domenami, wlasnie dlatego procentowy
Natomiast przyklad 2 prezentuje podzial tej samej plasz-czyzny na 4 domeny obliczeniowe. W kazdej domenie znajdujç siç w przyblizeniu tyle samo komórek jak w po-dziale z przykladu 1 ( 54 komórki ), zmianie ulegla ilosc komórek, które wymagaj^. komunikacji - np. w domenie 1 jest ich 9. Taka sam sytuacja miala miejsce w badanym scenariuszu symulacji, tyle ze podzial dotyczyl przestrze-ni, nie jak w przedstawionym przykladzie, plaszczyzny.
3.3. Stala wielkosc zadania, rosn^ca liczba w^tkôw
Obliczenia przeprowadzono przy uzyciu wersji FDS wykorzystuj^cej dyrektywy OpenMP [8]. W tym przypadku, cala przestrzen symulacji zostala okreslona w jednej domenie obliczeniowej. Domena byla podzielona na 152 256 komórek o rozmiarach ok. 0,64m x 0,67 m x 0,67 m kazda.
Tabela 8.
Czasy wykonania symulacji przy uzyciu roznej liczby wetkow, dla stalego rozmiaru zadania
Table 8
The time of the simulation using different numbers of threads, for a fixed size task
Liczba wetkow (Number of threads) Czas wykonania symulacji [sek] ' (Simulation execution time [sec]) Przyspieszenie obliczen (Acceleration calculations) Wydajnosc obliczen (Performance calculations)
1 9870.0 1.0 1.0
2 8835.0 1.117 0.557
3 7963.0 1.23 0.412
4 7876.0 1.253 0.312
Obliczenia dla domeny byly wykonywane przez pul§ wet-kow o roznej wielkosci, ktore zarzedzal system operacyjny [9]. Rozmiar puli wetkow byl okreslany r^cznie przed uru-chomieniem obliczen przez ustawienie zmiennej srodowi-skowej systemu operacyjnego OMP_NUM_THREADS na pozedane liczby wetkow. W przypadku obliczen prowadzo-nych przez wiele wetkow, kazdy z wetkow otrzymuje po-jedyncze zadanie, dla ktorego obliczenia moge byc prowadzone niezaleznie. Takim zadaniem moze byc wyznaczenie wielkosci dla jednej komorki domeny obliczeniowej dla pojedynczego kroku czasowej.
Eksperymenty numeryczne zostaly przeprowadzone na komputerze, ktorego parametry zostaly opisane w ta-beli 2. Do obliczen wykorzystano od 2 do 4 wetkow. Prze-prowadzono po 3 proby dla kazdej liczby wetkow. Punk-tem odniesienia wynikow byly czasy wykonania uzyskane przez wykonanie obliczen szeregowe wersje FDS. Sred-nie arytmetyczne otrzymanych czasow wykonania zostaly umieszczone w tabeli 8.
Otrzymane czasy wykonania symulacji wskazuje na niewielkie przyspieszenie obliczen uzyskane przez wyko-nywanie ich z uzyciem wielu wetkow. Dla badanej symu-
lacji maksymalne osiegni^te przyspieszenie wyznaczone zgodnie ze wzorem (1) nie przekroczylo poziomu 1,3 dla 4 wetkow wykonujecych zadanie. Dla liczby wetkow nie przekraczajecej 3 dodawanie kolejnego wetku do puli wykonujecej obliczenia skutkowalo wzrostem przyspie-szenia obliczen o okolo 10% w stosunku do obliczen prowadzonych przez wersje szeregowe FDS. Ta tenden-cja nie wyst^puje w przypadku dodania 4 wetku do puli wykonujecej obliczenia. Przyczyne takiego stanu jest to, ze w przypadku liczby wetkow mniejszej od liczby rdzeni procesora, wetki byly wykonywane na roznych rdzeniach, przez co nie konkurowaly ze sobe o przyznanie proceso-ra przez system operacyjny. Jeden z rdzeni pozostawal w znacznej mierze nie uzywany do obliczen, zwykle byl wykorzystywany do obslugi innych zadan systemu operacyjnego. W przypadku dodania 4 wetku do puli wykonujecej obliczenia, wetki byly wykonywane zwykle na osob-nych rdzeniach, ale pojawil si§ problem rywalizacji o czas procesora z innymi zadaniami systemu operacyjnego, czego efektem jest minimalny wzrost przyspieszenia przy wykonaniu obliczen przez 4 wetki w stosunku do obliczen wykonanych przez 3 wetki. Porownanie przyspieszenia
lk!ba watkow (number of threads)
|—pizyspieszenie OpenMP —pizygpiesierie Howe|
Ryc. 8. Przyspkszeme zdeznosci odficzbywetkow ^^^l^c^i^iy^c^^cli obhczenia
(pczy nZalym zoomiarze czdania oeiizzemowego). Fig. 8. Accelerationsakzlationdcpeodmg on tl^io numbcz of threadsperfomuzgcakruteiions
(with a fixed-size calculation task).
Ryc. 9. Wydajnosci systemu obliczen w zaleznosciod liczbyw^tkowwykomjcychobliczenia (przystalymrozmiarzezadaniaobliczeniowego). Fig. 9. Computingsystemperformancedepending on the number of threads performingcalculations
(atconstant size calculationtask).
............ ............ ............
V —
X \.......
............ ............ ......N \........ ............!""
\
--------- — — — ............ _____________ j-
..... .............. :»■■ 1:4. 1 .. i
1,00
2,00 3,00
liczba watkow
— wydafriosc OpenMP —state wydajnosc |
4,00
(number of threads)
obliczen, wyznaczonego zgodnie z wzorem (1), z przy-padkiem idealnego przyspieszenia liniowego prezentuje rysunek 8. Konsekwenj niewielkiego wzrostu przyspie-szenia obliczen jest spadaj^ca wydajnosc systemu, ktora zostala wyznaczona zgodnie ze wzorem (2). Porownanie wydajnosci z przypadkiem idealnym, gdy wydajnosc po-zostaje stala prezentuje rysunek 9.
3.4. Rosn^ca wielkosc zadania, rosn^ca liczba w^tkow
Podobnie jak w poprzednim przypadku opisanym w punkcie 3.3., obliczenia wykonano przy uzyciu wersji FDS wykorzystuj^cej dyrektywy OpenMP. Cala przestrzen symulacji zawierala si§ w obr^bie jednej domeny oblicze-niowej. Sterowanie liczby w^tkow odbywalo si§ przez ustawianie zmiennej srodowiskowej OMP_NUM_THRE-ADS systemu operacyjnego na poz^dan^. liczby w^tkow. W tym przypadku oprocz liczby w^tkow wykonuj^cych obliczenia, zmianie ulegal rowniez rozmiar zadania do wykonania. Zmiana rozmiaru zdania zostala osi^gni^ta przez zmian§ rozmiaru elementarnych komorek, na ktore
jest podzielona domena obliczeniowa. Przyj^to, ze zada-nie o rozmiarze dwukrotnie wi^kszym b^dzie wtedy, gdy liczba komorek w domenie b^dzie dwukrotnie wi^ksza. Niestety nie jest to przyblizenie idealne, gdyz rozny rozmiar komorek, moze miec bezposredni wplyw na otrzy-mane pr^dkosci przeplywu, ktore z kolei s^. podstaw^. do okreslenia, czy krok czasowy dla wykonywania obliczen nie jest zbyt duzy. Jezeli zmiana rozmiaru komorek b§-dzie miala wplyw na pr^dkosc przeplywu do tego stopnia, ze nie b^d^. spelnione warunki (11), b^dzie to oznaczac wi^cej obliczen niz wynikaloby to tylko z samego zwi^k-szenia liczby komorek. W przypadkach stworzonych do testow do takiej sytuacji nie dochodzilo, poniewaz uzyto stalej wartosci kroku czasowego, jednak dla bardziej zlo-zonych scenariuszy symulacji wyst^pienie tego zjawiska jest bardzo prawdopodobne.
Parametry komputera, na ktorym wykonano ekspe-rymenty przedstawia tabela 2. Do obliczen wykorzystano od 2 do 4 w^tkow. Przeprowadzono po 3 proby dla kaz-dej liczby w^tkow. Za punkt odniesienia do otrzymanych wynikow posluzyly czasy wykonania obliczen dla zadan
Tabela 9.
Czasy wykonania symulacji przy uzyciu roznej liczby w^tkow, dla rosn^cego rozmiaru zadania
Table 9.
The time of the simulation using different numbers of threads, the growing size of the task
Liczba w^tkow (Number of threads) Liczba komorek (Number of cells) Rozmiary komorek [m] (Cell .size [m]) Czas wykonania (OpenMP) [sek] (Execution time (OpenMP) [sec]) Czas wykonania (szeregowa) [sek] (Execution time (serial) [sec]) Wydajnosc (wg. wzoru 3) (Performance (according to formula 3))
1 40 000 1,1 x 1,08 x 1 3103.0 3103.0 1.0
2 81 900 0,87 x 0,83 x 0,8 4248.0 5328.0 0.627
3 121 110 0,79 x 0,77 x 0,8 6870.0 9540.0 0.463
4 152 256 0,7 x 0,67 x 0,67 7980.0 10790.0 0.338
Ryc. 10. Wydajnosc systemu obliczen przy rosnecym rozmiarze zadania obliczeniowego w funkcji liczby wetkow wykonujecych obliczenia Fig. 10. System performance calculations with the increasing size of computational tasks as a function of the number of threads performing calculations
o zwi^kszonych rozmiarach przez szeregowe wersj§ FDS. Srednie arytmetyczne czasow wykonania symulacji przez wej OpenMP oraz odpowiadajece im srednie czasow wykonania przez wej szeregowe, rozmiary zadan pre-zentuje tabela 9.
Eksperyment numeryczny z rosnece liczbe komorek do obliczen mial celu zbadanie skalowalnosci systemu. System nalezy rozumiec jako wspolzalezny kompleks: komputer + program do symulacji. Otrzymane w wyni-ku eksperymentow czasy wykonania symulacji z uzyciem roznej liczby wetkow wskazuje na niewielki zysk jezeli chodzi o skrocenie czasu wykonania symulacji w stosunku do zadania wykonywanego przez pojedynczy wetek. Za-chowanie si§ symulacji jest zblizone dla badanego przy-padku przy stalym rozmiarze zadania opisanego w punk-cie 3.3. Skrocenie czasu wykonania zadan, w stosunku do symulacji wykonywanych przez jeden wetek, rosnie o ok. 10 % przez dodanie kolejnego wetku do puli wykonujecej obliczenia. Nie dotyczy to liczby wetkow rownej 4, gdzie wzrost jest mniejszy - na poziomie ok. 5 %. Powody ta-kiej sytuacji zostaly opisane w punkcie 3.3. Nie znaczne skrocenie czasu wykonania oznacza spadajece wydajnosc systemu. Rysunek 10 pokazuje tendenj spadku wydaj-nosci systemu. Oznacza to, ze pomimo rownoczesnego dwukrotnego wzrostu rozmiaru zadania i dwukrotnego wzrostu liczby wetkow wykonujecych zadanie, nie udaj§ si§ utrzymac stalej wydajnosci systemu.
4. Podsumowanie
Modelowanie pozaru jest zagadnieniem trudnym do opisania matematycznie. Jeszcze trudniejsze jest przenie-sienie modelu matematycznego do odpowiednio szybkie-go i dokladnego oprogramowania, ktore b^dzie rozwiezy-wac ten model. Najcz^sciej wymienianym w publikacjach naukowych srodowiskiem do symulacji pozarow jest Fire Dynamics Symulator. FDS stworzono z mysle o uzyciu na
komputerach osobistych, przez co model matematyczny przeniesiony na grunt programu posiada wiele uproszczen. W wyniku rozwoju oprogramowania powstaly wersje, ktore wykorzystuje nowoczesne architektury procesorow wielordzeniowych oraz pozwalaje prowadzic obliczenia rownolegle na wielu komputerach poleczonych przy po-mocy sieci. Odmiana ograniczajeca si§ do wykorzystania do obliczen wielu rdzeni tego samego procesora zostala napisana przy uzyciu dyrektyw OpenMP, natomiast wer-sja rownolegla, ktora do obliczen moze uzywac zarowno komputerow poleczonych w siec, jak i wielu rdzeni jed-nego procesora korzysta z wywolan funkcji MPI. Z cale pewnoscie obie odmiany przyspieszaje obliczenia symulacji w stosunku do wykonania przez jeden rdzen procesora. Przeprowadzone w ramach pracy [4] eksperymenty numeryczne polegajece na pomiarze czasu wykonania tych samych zadan przez rozne wersje FDS, wykazaly, ze odmiane, ktora charakteryzowala si§ wi^kszym przy-spieszeniem obliczen w stosunku do wersji wykonywanej przez jeden rdzen procesora, byla wersja oparta o wywo-lania MPI. Idealnym wynikiem bylaby sytuacja, w ktorej zadanie wykonywane przez n procesorow wykonywalo si§ n razy krocej. Taka sytuacja w praktyce jest nie osie-galna poza pewnymi specyficznymi przypadkami. Wyni-ka to z faktu, iz w programie nie wszystkie czynnosci daje si§ zrownoleglic.
Otrzymane w wyniku eksperymentow czasy wy-konania symulacji przez wersje OpenMP byly znacze-co wyzsze niz MPI. Przykladowo, uzycie dwoch rdzeni procesora w przypadku MPI pozwolilo na skrocenie cza-su obliczen o blisko 30 % w stosunku do obliczen wy-konywanych przez jeden rdzen, natomiast w przypadku OpenMP w analogicznej sytuacji, udalo si§ skrocic obliczenia o nieco ponad 10 %. Wyniki te potwierdzaje opinie, jakie mozna odnalezc na oficjalnym forum internetowym projektu FDS odnosnie wersji MPI, ale rowniez potwier-
dzaje, deklaracje twórców na temat wersji OpenMP o nie-doskonalosci tej odmiany FDS, jezeli chodzi o uzyskane przyspieszenie obliczen.
Inna grupa eksperymentów numerycznych pozwoli-la zbadac skalowalnosc systemu rozumianego jako komputer wraz z oprogramowaniem. Równiez i w tym przy-padku otrzymane wyniki wykazaly, ze lepiej zachowuje siç wersja MPI - przy jednoczesnym proporcjonalnym zwiçkszaniu rozmiarów zadania obliczeniowego i liczby procesorów wykonujecych to zadanie, wydajnosc takiego systemu nieznacznie spadala. Jest to wynik zdecydowanie korzystny. Natomiast wersja OpenMP okazala siç nie ska-lowalne w przeprowadzonych eksperymentach.
Nalezy pamiçtac, ze wyniki moge siç róznic, w zalez-nosci od konkretnego scenariusza symulacji oraz zastoso-wanego podzialu zadania pomiçdzy procesory.
W trakcie definiowania scenariusza symulacji oraz jego testów wyszlo na jaw kilka problemów, z którymi mozna siç spotkac w trakcie definiowania przypadku. Pierwszym, bylo przenoszenie zdefiniowanego i testowa-nego scenariusza symulacji na systemie operacyjnym 32 - bitowym na system 64 - bitowy. Zdarzaly siç sytuacje, w których symulacje wykonywaly siç w pelni na jednym z systemów, natomiast na drugim ta sama symulacja, byla przerywana ze wzglçdu na niestabilnosc obliczen. Oznacza to, ze nalezy powaznie podchodzic do wskazó-wek okreslonych w [10] na temat unikania niestabilnosci obliczen, zwlaszcza wtedy, gdy definiowany scenariusz symulacji ma byc wykonywany na róznych platformach systemowych.
Drugim, istotnym spostrzezeniem, jest szybkosc wy-konywania siç symulacji na komputerach z procesorami róznych producentów: firmy Intel oraz AMD. Na proceso-rach Intel symulacje se wykonywane zdecydowanie szyb-ciej. Powodem tego jest kompilacja zródel przy uzyciu kompilatorów Intel zarówno do Fortrana i C++.
Pomimo podjçtych prób w trakcie pisania niniejszej pracy nie udalo siç uruchomic symulacji w wersji równole-glej FDS, wykorzystujecej MPI, na klastrze obliczeniowym Wydzialu Informatyki Politechniki Bialostockiej „Mordor 2". Problemem okazala siç nieobecnosc kompilatora For-tranu na wyzej wymienionym klastrze, natomiast rozpo-wszechniane na stronie projektu skompilowane wersje FDS nie dzialaly prawidlowo. Jest to z pewnoscie zagadnienie godne uwagi, dajece mozliwosc szerszego zbadania proble-matyki prowadzenia obliczen symulacji pozaru równolegle, z uzyciem wiçkszej liczby procesorów.
Literatura
1. Maciak T., Czajkowski J., Matematyczne modelowa-nie pozaru w pomieszczeniach zamkniçtych. [material przyjçty do publikacji];
2. Czajkowski P., Metody i algorytmy modelowania pozaru w pomieszczeniach zamkniçtych, praca dy-plomowa mgr., Politechnika Bialostocka, Wydzial Informatyki 2010. Promotor Maciak T.;
3. Fire Dynamics Simulator and Smokeview (FDS-SMV), [online], Official Website, Hosted at the National Institute of Standards and Technology (NIST), [on line] [dostçp 27.09.2012], Dostçpny w interne-cie: http://fire.nist.gov/fds/index.html ;
4. Chi-Ji Lin, Yew Khoy Chuah., A study on long tunnel smoke extraction strategies by numerical simulation, Tunnelling and Underground Space Technology, 2008, vol. 23. s. 522-530;
5. Silberschatz A., Galvin P. B., Podstawy systemow operacyjnych. Wydawnictwa Naukowo-Techniczne Warszawa:, 2005;
6. Oficjalna witryna internetowa projektu MPICH2 [on line] [dostçp 27.09.2012], Dostçpny w Internecie: http://www.mcs.anl.gov/research/projects/mpich2/ ;
7. Grama A., Gupta A., Karypis G., Kumar V., Introduction to Parallel Computing [online]. Wyd. 2. Essex: Addison - Wesley, 2003 [dostçp 27.09. 2012], Dostçpny w Internecie: http://books.google.com/ books?id=B3jR2EhdZaMC;
8. Oficjalna witryna internetowa projektu OpenMP, [on line] [dostçp 27.09 2012], Dostçpny w Internecie: http://openmp.org/ ;
9. Ben-Ari M., Podstawy programowania wspolbiez-nego i rozproszonego, Warszawa Wydawnictwa Na-ukowo-Techniczne, 1996;
10.0ficjalna witryna internetowa projektu MPICH2, [on line] [dostçp 27.09. 2012], Dostçpny w Internecie: http://www.mcs.anl.gov/research/projects/mpich2/ ;
dr hab. inz. Tadeusz Maciak
prof. SGSP urodzil siç 1949 roku w Warszawie. Studia na Wydziale Elektroniki Politechniki Warszawskiej ukon-czyl w roku 1973. Po studiach rozpoczel pracç w Instytu-cie Technologii Elektronowej Politechniki Warszawskiej (obecnie Instytut Mikro i Optoelektroniki). Zajmowal siç problemami zwiezanymi z optoelektronike. Pracç doktorske obronil na Wydziale Elektroniki Politechniki Warszawskiej w roku 1982. W roku 1991 rozpoczel pra-cç na Wydziale Informatyki Politechniki Bialostockiej. W roku 1994 obronil pracç habilitacyjne na Wydziale Elektroniki Politechniki Wroclawskiej. W roku 1998 rownolegle podjel pracç w Szkole Glownej Sluzby Po-zarniczej w Warszawie. W latach 2001-2006 Dziekan specjalnosci „Systemy Informatyczne w Technice i Za-rzedzaniu" w Wyzszej Szkole Ekonomiczno-Technicznej w Legionowie. W ostatnich latach jego zainteresowania koncentruje siç na wykorzystaniu aparatu informatycz-nego w rozwi^zywaniu zagadnien zwiezanych z ogolnie pojçtym bezpieczenstwem wewnçtrzny panstwa. Prowa-dzi prace zwiezane z problematyke procesu wspomaga-niu podejmowania decyzji w Panstwowej Strazy Pozar-nej. W krçgu jego zainteresowan znajduje siç rowniez wszelkiego typu symulacje komputerowe zagrozen po-zarowych oraz problematyka ewakuacji ludnosci z za-grozonych obiektow.
mgr inz. Przemyslaw Czajkowski
urodzil siç w 198V roku w Bialymstoku. W roku 2005, po skonczeniu IV Liceum Ogólnoksztalc^cego, rozpo-cz^l studia na Wydziale Informatyki Politechniki Bia-
lostockiej na specjalnosci Inzynieria Oprogramowania. Studia ukonczyl 2010 roku. Obecnie pracuje w firmie komputerowej w Bialymstoku.
