Analysis of the computational simulation of fire in the tunnel

Тип работы:
Реферат
Предмет:
История. Исторические науки


Узнать стоимость

Детальная информация о работе

Выдержка из работы

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& quot-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 sic 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 objctej symulacje. Wymiary przekroju poprzecznego przestrzeni przeznaczonej na ruch pojazdow wynosily odpowiednio 9,75 m szerokosci i 4.7 m wysoko-sci. Ponad jezdnie znajdowal sic szyb wentylacyjny nad cale szerokoscie i dlugoscie tunelu o wymiarach 9,75×1.8 m. Wymiary przekroju tunelu przedstawiono na rysunku 2.
A A
/ / / /
/ n a 1 wentytacyjny /
/ /
/ 3/
oluor wentylacyjny /

/
pi 1 /га ]'-(¦ г h и [& gt-'-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 sic dwa wentylatory wyciegajece powietrze. Zalozono, ze ich wydajnosc wynosila po 160 m3/s na dwoch koncach kanalu wentylacyjnego. Dodatkowo, przez wejscie do tunelu dostawal sic 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 domenc obliczeniowe wykonywanych przez wersjc szeregowe oprogramowania FDS, T (p) — czas obliczen, przy podziale na wiccej niz jedne do-menc obliczeniowe, wykonywanych przez wersjc 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 osiegnictego 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].
gcstosc (density) 2280 kg/m3
cieplo wlasciwe (specific heat) 1,04 kJ/kgK
przewodnictwo cieplne (thermal conductivity) 1,8 W/mK
emisyjnosc (emissivity) 0,9
wspolczynnik 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 komorek o rozmiarach ok. 0,69 m x 0,67 m x 0,67 m kazda. Liczby komorek przypadaj^cych na jcdn-| domcnp obliczeniow^ przedstawia tabela 3.
(n-l)-sza domena
obliczeniowa, i=0 — i=n-l
i& quot-… ^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 komorek w domenie (The number of cells in the domain) Liczba wszystkich komorek (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, 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 pro-cesow byl przydzielony do osobnego rdzenia procesora. Przydzielaniem procesow do procesorow zajmowal si§ system operacyjny [5]. Do komunikacji mi^dzy procesa-mi wykorzystano mechanizm Message Passing Interface (MPI) [6], ktory organizuje komputer w logiczn^. maszyn^ z pami^ci^. rozproszon^, pomimo, ze faktycznie, komputer uzyty do przeprowadzenia eksperymentu byl maszyn^. ze wspoln^ pami^ci^. [7].
Srednie arytmetyczne otrzymanych czasow wykonania symulacji zawiera tabela 4.
Wyznaczone na podstawie wzoru (1) przyspieszenie uzyskane w wyniku dodawania kolejnych procesorow pre-zentuje tabela 4. Otrzymane wyniki dla 2 i 3 procesorow 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® Core™ 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
Szczegolowe 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.
Porownanie przyspieszenia z przypadkiem idealnym — przyspieszeniem liniowym, prezentuje rysunek 4.
3.1.1. Komunikacja miqdzy procesami
W przypadku podzialu zadania pomi^dzy kilka proce-sorow, poszczegolne domeny obliczeniowe musze si§ na-wzajem komunikowac w celu wymiany wartosci wyzna-czanych wielkosci fizycznych przylegajecych granicach. Wymianie podlegaje wielkosci z granicznych komorek obliczeniowych sesiadujecych domen. Czas poswi^cony na komunikacja moze byc odczytany z plikow wyjscio-wych otrzymanych w wyniku obliczen. Przy stalym roz-miarze zadania obliczeniowego wraz ze wzrostem liczby domen obliczeniowych, na ktore dzieli si§ przestrzen sy-mulacji, rosnie liczba komorek, dla ktorych do obliczen se potrzebne wartosci z sesiedniej domeny obliczeniowej.
i=0
(n-l)-sza domena 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 komorki wystcpuj^. na granicach przyleglych domen obliczeniowych. Przyklad takiej sytuacji na plaszczyznie prezentuje rysunek 5, gdzie zaprezentowano podzial pro-stok^tnej plaszczyzny na n czcsci. Kazda z n czcsci jest podzielona na komorki obliczeniowe. Czerwonymi liniami zostaly zaznaczone granice przylegaj^cych domen. Szarym kolorem wypelniono komorki, dla ktorych wyma-gana jest wymiana informacji z komorkami z s^siedniej domeny.
W przypadku przeprowadzonych eksperymentow 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 wzglcdu na redukcjc ilosci komorek, ktore wymagaj^. komunikacji z s^siedni^. domeny — powierzchnia styku s^siednich domen jest przy takim podziale najmniejsza.
Otrzymany procentowy udzial czasu poswiccone-go na komunikacjc micdzy 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 sic pomicdzy nimi, obejmuje ob-szar, gdzie znajduje sic zrodlo ognia. Domeny l oraz З nie komunikuj^. sic ze sob^. bezposrednio, a гоЫц. to jedynie z domeny 2. Natomiast domena 2, musi komunikowac sic z dwoma s^siaduj^cymi domenami, czyli dwa razy wiccej komorek wymaga wymiany informacji niz w domenach l i З. Wyjasnia to, dlaczego pomimo wickszego zadania ob-liczeniowego z tytulu obecnosci zrodla ognia w domenie 2, procentowo poswiccony czas na komunikacjc stanowi wicksz^. czcsc 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 komorek w poszczegolnych domenach, jak w przypadku З procesorow, procentowe udzialy ko-
Tabela 5.
Procentowy udzial czasu poswicconego na komunikacjc w poszczegolnych domenach obliczeniowych w stosunku do calego czasu obliczen, przy uzyciu roznej liczby procesow, 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 procesorow (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 czasow poswicconych na komunikacjc w domenach obliczeniowych rozni^. sic micdzy sob^. na-wet w obrcbie tego samego przypadku (w domenach obliczeniowych dla tego samego zadania). Np. dla przypadku wykonywanego przez 2 procesory czasy poswiccone na komunikacjc s^. rozne, pomimo tego, ze dwie domeny obejmuje fragmenty przestrzeni symulacji o dokladnie takich samych wymiarach, dokladnie taka sama jest tez ilosc komorek, ktore wymagaj^. wymiany informacji. Po-wodem takiego stanu jest niesymetryczny charakter po-dzialu przestrzeni symulacji — w jednej z domen znajduje sic zrodlo ognia oraz otwor wentylacyjny, co powodujc obecnosc dodatkowych obliczen w tej domenie ponad ob-liczenia wykonywane, w drugiej z domen, gdzie oblicze-nia dotycz^. jedynie przeplywu gazow, rozprzestrzeniania sic ciepla i nagrzewania sic scian tunel. Oznacza to, ze taki sam czas poswiccony na komunikacjc bcdzie stanowil mniejszy procent calych obliczen w przypadku domeny 2
munikacji micdzy domenami s^. wicksze niz wariantu z podzialem na З domeny. Dziejc sic tak, poniewaz domeny obejmuje mniejsze fragmenty przestrzeni symulacji, co oznacza mniejsze zadania obliczeniowe, natomiast ilosc komorek, dla ktorych nalezy wymienic informacje pomic-dzy domenami jest taka sama.
3.2. Rosn^cy rozmiar zadania, rosn^ca liczbapro-cesorow
Obliczenia przeprowadzono przy uzyciu wersji FDS wykorzystuj^cej wywolania MPI. Scenariusze symulacji zostaly zdefiniowane w ten sposob, 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 sic jeden rdzen procesora. Zamiana rozmiaru zadania zostala osi^gnicta przez zmianc rozmiaru komorek, na ktore 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×1,08×1 3103.2 3103.2 1. 0
2 81 900 0,87×0,83×0,8 3026.2 5328.0 0. 88
3 121 110 0,79×0,77×0,8 3816.0 9540.0 0. 833
4 152 256 0,7×0,67×0,67 4248.0 10 790.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. Porownanie uzyskanej wydajnosci prezentuje wykres 6.
udzial komunikacji rosl wraz ze wzrostem liczby komo-rek. Tak^. sytuacjc na plaszczyznie prezentuje rysunek 7.
W przykladzie 1 z rysunku 7 plaszczyzna zostala po-dzielona na dwie domeny, kazda po 48 komorek. W tym przypadku w domenie 1, wymiany informacji z domeny 2 wymaga 6 komorek (komorki zaznaczone na szaro).
Tabela 7.
Procentowy udzial czasu poswicconego na komunikacjc 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 procesorow (Number of processors) Procent calkowitego czasu obliczen poswiccony 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
domena 1
domena 2
Przyklad 2










domena 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 micdzy procesami Procentowy udzial czasu poswicconego na komunikacjc pomicdzy domenami w stosunku do calego czasu
obliczen w poszczegolnych domenach przedstawia tabela 7. Do zjawisk opisanych w punkcie 3.1.1., ktore takze do-tycz^. eksperymentu z rosn^cym rozmiarem zadania obli-czeniowego, dochodzi jeszcze jedno. W tym przypadku liczba komorek w domenie obliczeniowej byla podobna niezaleznie od liczby procesorow wykonuj^cych zadania. Zostalo to osi^gnicta przez zwickszanie liczby komorek w domenie obliczeniowej wraz ze wzrostem liczy procesorow wykomjcych zadanie. Zatem mozna uznac, ze samo zadanie obliczeniowe bylo stale, zmieniala sic natomiast liczba komorek dla ktorych nalezalo wymienic informa-cjc z s^siednimi domenami, wlasnie dlatego procentowy
Natomiast przyklad 2 prezentuje podzial tej samej plasz-czyzny na 4 domeny obliczeniowe. W kazdej domenie znajdujc sic w przyblizeniu tyle samo komorek jak w po-dziale z przykladu 1 (54 komorki), zmianie ulegla ilosc komorek, ktore 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^tkow
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 komorek 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×1,08×1 3103.0 3103.0 1. 0
2 81 900 0,87×0,83×0,8 4248.0 5328.0 0. 627
3 121 110 0,79×0,77×0,8 6870.0 9540.0 0. 463
4 152 256 0,7×0,67×0,67 7980.0 10 790.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 tworcow na temat wersji OpenMP o nie-doskonalosci tej odmiany FDS, jezeli chodzi o uzyskane przyspieszenie obliczen.
Inna grupa eksperymentow numerycznych pozwoli-la zbadac skalowalnosc systemu rozumianego jako komputer wraz z oprogramowaniem. Rowniez i w tym przy-padku otrzymane wyniki wykazaly, ze lepiej zachowuje sic wersja MPI — przy jednoczesnym proporcjonalnym zwickszaniu rozmiarow zadania obliczeniowego i liczby procesorow wykonujecych to zadanie, wydajnosc takiego systemu nieznacznie spadala. Jest to wynik zdecydowanie korzystny. Natomiast wersja OpenMP okazala sic nie ska-lowalne w przeprowadzonych eksperymentach.
Nalezy pamictac, ze wyniki moge sic roznic, w zalez-nosci od konkretnego scenariusza symulacji oraz zastoso-wanego podzialu zadania pomicdzy procesory.
W trakcie definiowania scenariusza symulacji oraz jego testow wyszlo na jaw kilka problemow, z ktorymi mozna sic spotkac w trakcie definiowania przypadku. Pierwszym, bylo przenoszenie zdefiniowanego i testowa-nego scenariusza symulacji na systemie operacyjnym 32 — bitowym na system 64 — bitowy. Zdarzaly sic sytuacje, w ktorych symulacje wykonywaly sic w pelni na jednym z systemow, natomiast na drugim ta sama symulacja, byla przerywana ze wzglcdu na niestabilnosc obliczen. Oznacza to, ze nalezy powaznie podchodzic do wskazo-wek okreslonych w [10] na temat unikania niestabilnosci obliczen, zwlaszcza wtedy, gdy definiowany scenariusz symulacji ma byc wykonywany na roznych platformach systemowych.
Drugim, istotnym spostrzezeniem, jest szybkosc wy-konywania sic symulacji na komputerach z procesorami roznych producentow: firmy Intel oraz AMD. Na proceso-rach Intel symulacje se wykonywane zdecydowanie szyb-ciej. Powodem tego jest kompilacja zrodel przy uzyciu kompilatorow Intel zarowno do Fortrana i C++.
Pomimo podjctych prob w trakcie pisania niniejszej pracy nie udalo sic uruchomic symulacji w wersji rownole-glej FDS, wykorzystujecej MPI, na klastrze obliczeniowym Wydzialu Informatyki Politechniki Bialostockiej «Mordor 2& quot-. Problemem okazala sic 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 rownolegle, z uzyciem wickszej liczby procesorow.
Literatura
1. Maciak T., Czajkowski J., Matematyczne modelowa-nie pozaru w pomieszczeniach zamknictych. [material przyjcty do publikacji]-
2. Czajkowski P., Metody i algorytmy modelowania pozaru w pomieszczeniach zamknictych, 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] [dostcp 27. 09. 2012], Dostcpny 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] [dostcp 27. 09. 2012], Dostcpny 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 [dostcp 27. 09. 2012], Dostcpny w Internecie: http: //books. google. com/ books? id=B3jR2EhdZaMC-
8. Oficjalna witryna internetowa projektu OpenMP, [on line] [dostcp 27. 09 2012], Dostcpny 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] [dostcp 27. 09. 2012], Dostcpny w Internecie: http: //www. mcs. anl. gov/research/projects/mpich2/ -
dr hab. inz. Tadeusz Maciak
prof. SGSP urodzil sic 1949 roku w Warszawie. Studia na Wydziale Elektroniki Politechniki Warszawskiej ukon-czyl w roku 1973. Po studiach rozpoczel pracc w Instytu-cie Technologii Elektronowej Politechniki Warszawskiej (obecnie Instytut Mikro i Optoelektroniki). Zajmowal sic problemami zwiezanymi z optoelektronike. Pracc doktorske obronil na Wydziale Elektroniki Politechniki Warszawskiej w roku 1982. W roku 1991 rozpoczel pra-cc na Wydziale Informatyki Politechniki Bialostockiej. W roku 1994 obronil pracc habilitacyjne na Wydziale Elektroniki Politechniki Wroclawskiej. W roku 1998 rownolegle podjel pracc w Szkole Glownej Sluzby Po-zarniczej w Warszawie. W latach 2001−2006 Dziekan specjalnosci «Systemy Informatyczne w Technice i Za-rzedzaniu& quot- w Wyzszej Szkole Ekonomiczno-Technicznej w Legionowie. W ostatnich latach jego zainteresowania koncentruje sic na wykorzystaniu aparatu informatycz-nego w rozwi^zywaniu zagadnien zwiezanych z ogolnie pojctym bezpieczenstwem wewnctrzny panstwa. Prowa-dzi prace zwiezane z problematyke procesu wspomaga-niu podejmowania decyzji w Panstwowej Strazy Pozar-nej. W krcgu jego zainteresowan znajduje sic rowniez wszelkiego typu symulacje komputerowe zagrozen po-zarowych oraz problematyka ewakuacji ludnosci z za-grozonych obiektow.
mgr inz. Przemyslaw Czajkowski
urodzil sic w 198V roku w Bialymstoku. W roku 2005, po skonczeniu IV Liceum Ogolnoksztalc^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.

ПоказатьСвернуть
Заполнить форму текущей работой