Hruba kontrola spravne funkcnosti a presnosti algoritmu
jiz byla provedena na kruznici, kde je znamo analyticke reseni. Tady se budeme
venovat paralelizaci. A tady uz se vali prvni kompletni sada testu, ktera
si klade za cil overit, zda je paralelizace provedena spravne. Jako testovaci
priklad jsem vzal stahujici se 'petiuhelnik' s nasledujicimi parametry:
Stred opsane kruznice = [ 2.0, 2.0 ]
Polomer = 1.35
Zeta = 0.034
M_fold = 5
Force = 0.0
Alpha = 1.0
Velikost oblasti pri mrizce procesu = [ 0.0 - 4.0, 0.0 - 4.0 ]
Prostorovy krok = 0.02
Pocatecni cas = 0.0
Casovy krok = 5e-5
Koncovy cas = 0.9
Epsilon^2 = 1e-10
Rozmery oblasti pri narrow bandu - 25 x 25 bodu
Vypocet jsme provedli za velice pocetnych reinicializaci (cca. 7), aby se projevilo co nejvice chyb. Prvni obrazek ukazuje porovnani sekvencniho kodu, mrizky (2 x 2 procesy) a narrow bandu (2 procesy) v case koncovem case 0.9000.
Modra - sekvencni algoritmus, Zelena - mrizka procesu, Cervena - narrow band. Odchylky mezi mrizkou procesu a sekvencnim algoritmem jsom relativne male (vzhledem ke kroku 0.02) a dosahuji maxima v bode nejvetsi anizotropie. Vysledky narrow band verze jsou pochopitelne zatizeny vetsi chybou, ale i tento vysledek se mi jevi jako velice pozitivni.
V dalsi simulaci jsme se zamerili na zmenu vysledku pri pouziti vetsiho poctu procesu - konkretne 2, 4 a 16 pri narrowbandu a 4, 8 a 16 pri mrizce.
Na mrizce procesu by meli byt zmeny temer nemeritelne, coz se potvrdilo. Jako finalni nevizualni kontrola spravnosti byla do programu vlozena rutina, ktera prubezne a nahodne kontrolovala behem vypoctu, ze vsechny procesy pocitaji na stejnych datech (v mistech prekryvu). Vsechno se zda byt v poradku.
Co se narrow bandu tyce, jsou drobne problemy pri vetsim poctu procesu, protoze se zacinaji prekryvat i procesy, se kterymi program nepocita (je implementovany prekryv jen dvo po sobe jdoucich procesu). Z tohoto duvodu bylo provedeno provonani na drivejsi casove hladine 0.8550. Cervena - 2, Zelena - 4, Modra - 16 procesu. Vysledky se mi jevi jako opet uspokojujici. Nutno podotknout, ze simulace na 8 procesech zkolabovala na drivejsi casove hladine a i 16 procesova verze skoncila chybou. Domnivam, ze je to zpusobeno prave nekonzistenci na malych vzdalenostech, kdy mu neco jednoduse nesedne... Chtelo by to nejaky mechnizmus, co by automaticky snizoval poce pouzitych procesu behem vypoctu.
Stred opsane kruznice = [ 2.0, 2.0 ]
Polomer = 1.35
Zeta = 0.034
M_fold = 5
Force = 0.0
Alpha = 1.0
Velikost oblasti pri mrizce procesu = [ 0.0 - 4.0, 0.0 - 4.0 ]
Prostorovy krok = 0.02
Pocatecni cas = 0.0
Casovy krok = 5e-5
Koncovy cas = 0.9
Epsilon^2 = 1e-10
Rozmery oblasti pri narrow bandu - 25 x 25 bodu
Vypocet jsme provedli za velice pocetnych reinicializaci (cca. 7), aby se projevilo co nejvice chyb. Prvni obrazek ukazuje porovnani sekvencniho kodu, mrizky (2 x 2 procesy) a narrow bandu (2 procesy) v case koncovem case 0.9000.
| Koncovy cas 0.9, porovnani metod |
|
Modra - sekvencni algoritmus, Zelena - mrizka procesu, Cervena - narrow band. Odchylky mezi mrizkou procesu a sekvencnim algoritmem jsom relativne male (vzhledem ke kroku 0.02) a dosahuji maxima v bode nejvetsi anizotropie. Vysledky narrow band verze jsou pochopitelne zatizeny vetsi chybou, ale i tento vysledek se mi jevi jako velice pozitivni.
V dalsi simulaci jsme se zamerili na zmenu vysledku pri pouziti vetsiho poctu procesu - konkretne 2, 4 a 16 pri narrowbandu a 4, 8 a 16 pri mrizce.
| Mrizka procesu |
Narrow band |
|
|
Na mrizce procesu by meli byt zmeny temer nemeritelne, coz se potvrdilo. Jako finalni nevizualni kontrola spravnosti byla do programu vlozena rutina, ktera prubezne a nahodne kontrolovala behem vypoctu, ze vsechny procesy pocitaji na stejnych datech (v mistech prekryvu). Vsechno se zda byt v poradku.
Co se narrow bandu tyce, jsou drobne problemy pri vetsim poctu procesu, protoze se zacinaji prekryvat i procesy, se kterymi program nepocita (je implementovany prekryv jen dvo po sobe jdoucich procesu). Z tohoto duvodu bylo provedeno provonani na drivejsi casove hladine 0.8550. Cervena - 2, Zelena - 4, Modra - 16 procesu. Vysledky se mi jevi jako opet uspokojujici. Nutno podotknout, ze simulace na 8 procesech zkolabovala na drivejsi casove hladine a i 16 procesova verze skoncila chybou. Domnivam, ze je to zpusobeno prave nekonzistenci na malych vzdalenostech, kdy mu neco jednoduse nesedne... Chtelo by to nejaky mechnizmus, co by automaticky snizoval poce pouzitych procesu behem vypoctu.