Bc. Štěpán Balcar. Heterogenní ostrovní modely

Transkript

1 DIPLOMOVÁ PRÁCE Bc. Štěpán Balcar Heterogenní ostrovní modely Katedra teoretické informatiky a matematické logiky Vedoucí diplomové práce: Mgr. Martin Pilát, Ph.D. Studijníprogram: Informatika Studijní obor: Softwarové systémy Praha 2017

2 Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů, literatury a dalších odborných zdrojů. Berunavědomí,žesenamojiprácivztahujíprávaapovinnostivyplývajícíze zákona č. 121/2000 Sb., autorského zákona v platném znění, zejména skutečnost, že Univerzita Karlova má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V...dne... Podpisautora i

3 Název práce: Heterogenní ostrovní modely Autor: Bc. Štěpán Balcar Katedra: Katedra teoretické informatiky a matematické logiky Vedoucí diplomové práce: Mgr. Martin Pilát, Ph.D., katedra Abstrakt: Práce se zabývá heterogenními ostrovními modely. Navrhuje a implementuje nový ostrovní model na základě poznatků o homogenních modelech v oblasti evolučních algoritmů. Model umožňuje dynamické přeplánovávání obecných výpočetních metod. Práce experimentálně porovnává výsledky homogenních a heterogenních modelů. Klíčová slova: distribuované evoluční algoritmy, adaptabilita, heterogenní ostrovní architektura Title: Heterogeneous Island Models Author: Bc. Štěpán Balcar Department: Department of Theoretical Computer Science and Mathematical Logic Supervisor: Mgr. Martin Pilát, Ph.D., department Abstract: The work deals with heterogeneous island models. The work designs and implements a new island model based on knowledge of homogeneous models of evolutionary algorithms. The model allows dynamic replanning of general computational methods. The work experimentally compares results of homogeneous and heterogeneous models. Keywords: distributed evolutionary algorithms, adaptability, island architecture ii

4 Chtěl bych poděkovat svému vedoucímu Mgr. Martinovi Pilátovi, Ph.D. za odborné vedení diplomové práce a panu Mgr. Romanovi Nerudovi, CSc. za možnost konzultace svých nápadů. Dále děkuji všem, kteří mi v průběhu psaní práce pomáhali a dodávali energii. iii

5 Obsah Úvod 4 1 Evoluční algoritmy 5 Vznik Schémagenetickéhoalgoritmu... 5 Hybridnígenetickéalgoritmy... 9 Paralelizacegenetickýchalgoritmů Dalšímetody Hill-climbing StochastickýHill-climbing Randomsearch Simulovanéžíhání Tabusearch Diferenciálníevoluce BruteForce(Hrubásíla) Ostrovní modely 15 Farmářskýmodel Migrační(ostrovní)model Celulární(difuzní)model Hierarchicképaralelnímodely Základní typy problémů 18 Problémobchodníhocestujícího Binpackingproblém Strojovéučení Spojitéoptimalizace Problémminimálníhovrcholovéhopokrytí Související práce 23 Rozdílnéparametry Rozdílnémetody Multiagentní systémy 24 Pohleddohistorie Agent Ontologie Komunikačníprotokoly Inspirováníseagenty Analýza systému 27 Vzniklýsystém Případyužití Soupisfunkčníchpožadavků Konceptarchitekturymodelu Základníobjekty

6 Závislostnavstupnímproblému Vlastnostiostrovníchmodelů Definicevstupu Transformacevstupníjobstruktury PopismoduluPlánovače Technologie Volbatechnologie Implementacenovéhoostrovníhomodelu Plánovačajehovstupy Rozvrženíinfrastrukturníchslužebdoagentů DefinicerozhraníProblemToolnástroje Upravené algoritmy pro nový ostrovní model 46 AgentBruteForce AgentEvolution AgentHillClimbing AgentRandomSearch AgentSimulatedAnnealing AgentTabuSearch AgentDifferentialEvolution NamapováníalgoritmůnaProblemToolnástroj NástrojeTSPproblému NástrojeBinPackingproblému Nástrojeproblémustrojovéučení Nástrojeproblémuspojitáoptimalizace Nástrojeproblémuvrcholovéhopokrytí Plánovače 59 Interakceplánovačesokolím Implementovanéplánovače InicializačníPlánovače Plánovačrandom Plánovačrandomzaručujícíšanci Plánovačpopismetody(AgentInfo) Plánovačnejlepšípomocník Plánovačnejlepšíprůměrnáfitness Plánovačnejvětšípočetvylepšení Plánovačkvalitnígenetickýmateriál Plánovačnejvětšímnožstvígenetickéhomateriálu Plánovačnejvětšíelitaazlepšeníanejlepšíprůměrfitness Plánovač největší množství materiálu, dobrého materiálu a zlepšení.. 67 Plánovačrodokmen Plánovačlínýmaximalizujícípočetvylepšení Výsledky měření 70 TestyproblémuTSP TestováníTSP TestováníTSP TestyBinPackingproblému

7 TestováníBPP Testyproblémuspojitéoptimalizace TestováníCOf TestováníCOf TestováníCOf TestováníCOf Testyproblémuvrcholovéhopokrytí TestováníVCfrb TestováníVCfrb Testyproblémustrojovéhoučení TestováníMLWilt Zhodnocenívýsledků Vylepšení systému 101 Závěr 103 Seznam obrázků 108 Seznam tabulek 110 3

8 Úvod Cílem práce je zkoumat heterogenní ostrovní modely a posoudit jejich praktickou využitelnost. Termín ostrovní modely, myšleno homogenní, se objevuje u evolučních algoritmů jako prostředek pro paralelizaci. Heterogenní modely by měly být jiné právě v možnosti spouštět v modelu více různých prohledávacích algoritmů. Modely budeme z historického i praktického pohledu definovat jako přístup tvořící nadstavbu nad evolučními algoritmy. Evoluční algoritmy vznikly jako programátorská technika inspirovaná fungováním světa přírody. Hlavní myšlenkou je reprezentovat množinu řešení konkrétního problému jako systém, který se nechá adaptabilně vyvíjet. Schopnost přežít azreprodukovatse,jezárukoukvalityjedincůkaždégeneraceatoivesvětěalgoritmů. Využití našly jako stochastická optimalizační technika, využívající se pro řešení těžkých problémů. Možnost efektivního prohledávání stavového prostoru sice nezaručí optimální řešení, ale dává velkou pravděpodobnost se k optimu touto technikou úzce přiblížit. Jako u každé výpočetní techniky se svět vědy začal zabývat způsoby zvyšování její efektivity. Využití paralelizace se u stochastických algoritmů, spouštěných vždy v několika sekvenčních bězích neskrývaně nabízela. Ostrovní modely přišly s přístupem paraleního běhu evolučních algoritmů, které spolupracují a vyměňují si své výsledky. Cílem práce je prozkoumat poznatky o homogenních ostrovních modelech a snažitsenajítzpůsob,jakjezobecnittak,abyvnichmohlysoučasněpočítat různé metody. Model tedy předpokládá, že budeme mít k dispozici více výpočetních algoritmů. V rámci takového počítání přichází ale ještě před spuštěním výpočtu nutnost výběru optimální podmnožiny metod. Takovýto výběr je těžké správně učinit bez znalosti vstupního problému. Tento problém bude řešen dynamickým přeplánováváním. Dynamičnost volby metod přináší i možnost adaptivně reagovat na fázi výpočtu. Od návrhu obecného heterogenního modelu si slibujeme zvýšení buď efektivity nebo univerzálnosti prostředku. Tuto hypotézu nebudeme schopni prokázat jinak než experimentálně. Tudíž součástí práce bude implementace nového modelu včetně metod. Testy, na kterých budeme provádět experimenty, budou postaveny na několika různých typech problémů. Půjde jak o spojité optimalizace, tak o kombinatorické problémy. 4

9 1. Evoluční algoritmy Vdobě,kdysilidézačaliuvědomovat,žepřírodaokolonásjeschopnápostupnou adaptací řešit netriviální problémy, se kterými se potýkají jak rostliny, tak živočišné druhy, začaly se při návrhu nových algoritmů zkoušet používat schopnosti a dosud známé fakty o fungování ekosystému. V této kapitole se seznámíme s obecnými principy evolučních algoritmů. Následuje obecný přehled algoritmů. Detaily si popíšeme později v konkrétních souvislostech. Vznik Největší inspirací pro návrháře algoritmů se stala Darwinova teorie[13]. Snaha využít v informatice princip přežití silnějšího, spojená s programátorskou genetikou, se stala základním kamenem pro algoritmicky stochastické vylepšování řešení problému. Evoluční algoritmy se staly populárními až po roce 1970, kdy John Holland vydal knihu o umělém životě[27]. Jako první se touto problematikou zabýval už v roce 1954 Nils Aall Barricelli[5]. Od té doby našly uplatnění při řešení širokého spektra obecných problémů. Evoluční algoritmy zastřešují několik technik: genetické algoritmy, genetické programování, evoluční strategie, evoluční programování. Schéma genetického algoritmu Evoluční algoritmus pracuje v několika fázích, které[16] se cyklicky opakují. Základní snahou algoritmu je iterativní vylepšování množiny řešení problému. Množinu zakódovaných řešení nazýváme populací, a samotné řešení nazýváme jedincem. Prvním krokem evolučního algoritmu(viz obr. 1.1) je vytváření nulté populace jedinců. Tato populace se většinou generuje náhodně. Následně se pořád dokola opakují fáze ohodnocování, selekce, křížení a mutace. Každé opakování nazýváme další generací evoluce. Výpočet končí v okamžiku nesplnění podmínky pro další iteraci cyklu algoritmu. Důvodem může být buď nalezení dostatečně dobrého řešení nebo překročení limitu na dostupný výpočetní výkon. 5

10 Obrázek 1.1: Schéma evolučního algoritmu Genotyp a fenotyp jedince Pojem genotyp v oblasti umělého života představuje soubor informací o genetické konstrukci organismu. Genotyp konkrétního jedince obsahuje celou jeho genetickou charakteristiku. Chromozom zapouzdřuje strukturu genů různého typu nebo-li alel. Jedinec slouží k reprezentaci jednoho řešení a představuje takzvaný fenotyp. Fenotyp je výsledek projevení genotypových informací do znaků organizmu. Podle zakódování rozlišujeme přímou a nepřímou reprezentaci. Přímá reprezentace často u problémů přináší nutnost specifické reprezentace řešení. U nepřímé reprezentace si většinou vystačíme s datovými strukturami permutací, vektorem hodnot, stromem nebo jiným grafem. Definice ohodnocovací funkce Ohodnocovací funkce určuje kvalitu jedince. Volba funkce záleží na tom, zda evoluce má řešit maximalizační nebo minimalizační úlohu. Ve spolupráci se selekcí do další generace přežijí jen zdatní a perspektivní jedinci. Selekce Představuje metodu, jakým způsobem vybrat ze stávající populace jedince, ze kterých se bude za pomoci operátorů vytvářet populace následující generace. Přirozený Darwinovský výběr není zcela náhodný. Jedinci rozlišují mezi příbuznými a partnery si vybírají podle kritérií. Jako Panmiktickou populaci naopak označujeme model, kdy výběr partnerů je zcela náhodný. Selekce jsou navrhovány s úsilím na vybírání lepších jedinců s větší pravděpodobností, zároveň s možností poskytnout těm nejhorším alespoň malou šanci na výběr. Mezi nejznámější příklady selekcí patří: ruletová selekce, pořadová selekce, turnajová selekce. 6

11 Ruletová selekce Ruletová selekce provádí výběr náhodně na základě pravděpodobností, které jsou přiřazeny jedincům. Pravděpodobnost výběru jedinci přiřazená je přímo úměrně závislá na jeho fitness. Název selekce je inspirovaný analogií rulety, kde se dopočítají šířky úsečí v závislosti na hodnotě jedince. Jednoduchou modifikací poměrů můžeme získat pořadovou selekci. Jedná se jen o způsob přeškálování míry důležitosti jedinců vstupující do rulety. Poměr jedince není určen hodnotou ohodnocení, ale pozicí v uspořádání podle fitness. Turnajová selekce Vznik turnajové selekce inspirovaly bitvy o partnery probíhající v přírodě. Výběr se připodobňuje k turnaji, do kterého vstupuje náhodně zvolená podmnožina jedinců. Jedinci vzájemně vyřazují a pro křížení je vybrán pouze vítěz turnaje. V každém souboji vyhrává se zadanou pravděpodobností jedinec s vyšší fitness. Pro každé selektované individuum se pořádá nový turnaj. Přinášenou výhodou selekce představuje regulovaný selekční tlak, nejlepší jedinci nejsou nepřiměřeně upřednostňováni. To zabraňuje předčasné konvergenci. Zároveň zde ale nemáme jistotu přežití nejlepšího jedince. Elitismus Elitismus je konstrukt, který slouží k zaručení nezhoršujícího vývoje evoluce. Nejlepší jedinec z generace je automaticky přidán do následující generace a to bez toho, aby na něm byly volány operátory. Jednoduše se tak docílí situace, kdy se výsledek evoluce napříč generacemi bude mít možnost pouze zlepšovat. Explorace a Exploatace Hlavním benefitem evoluce je schopnost nalézt kvalitní řešení problému bez toho, aby se musel projít celý prostor všech řešení. Protože je hledání náhodné a procházejí se vždy jen jednotlivé body, je zde potřeba brát důraz na smysluplné a efektivní prohledávání stavového prostoru řešení. Způsob prohledávání popisují pojmy explorace a exploatace. Explorace zajišťuje procházení dosud nenavštívených oblastí. Exploatace obstarává dohledávání maxim a minim v globálních extrémech. Pro optimální chod evoluce musí být obě veličiny v rovnováze. Operátory Operátory a pravděpodobnosti jejich aplikace jsou nástroje na ovlivňování správného poměru explorace a exploatace v rámci evoluce. Patří mezi ně křížení a mutace. Evoluce nutně nemusí používat oba tyto operátory. Při řešení určitých problémů a při použití přímých reprezentací se často operátor křížení vůbec nepoužívá. Při popisech operátorů budeme uvádět příklady operátorů nepřímé reprezentace. 7

12 Operátory mutace Mutace jako operátor byla navržena jako náhodný zásah do jedince ve snaze pokusit se napravit nějakou nedokonalost. U permutace se nabízí různé náhodné přesuny alel genotypu. U pole hodnot přichází v úvahu i úprava hodnot. Koncepce mutací u stromů může mít buď formu prořezávání nebo transformace grafu. (a) Operátor SimpleSwap nad permutací (b) Operátor SimpleSwap nad stromem Jako příklad uvedeme operátor SimpleSwap ve variantě nad permutací(viz obr.1.2a)inadstromem(vizobr.1.2b).upermutacejsounáhodnězvolenydvě různé alely, prohozením jejich hodnot vznikne nový jedinec. U stromů se vybírají dva různé vrcholy a nový jedinec vznikne prohozením dvou podstromů. Operátory křížení Operátor křížení pracuje se dvěma vstupními jedinci, ze kterých specifickým postupem vytváří nového jedince. Cílem je vytvořit nový genetický materiál, který by mohl obohatit novou populaci. Postup vytváření úzce souvisí se zakódováním jedince. Křížení je nepovinný operátor, někdy může být pro prohledávání efektivnější použít v algoritmu pouze mutaci. Popíšeme si zde obecné operátory pracující nad seznamem hodnot. U jednobodového křížení(viz obr. 1.3a) se chromozom jedince rozdělí na náhodně zvoleném místě. Na stejném místě se rozsekne i druhý jedinec. Jedinci si jednu část vzájemně vymění a vzniknou dva noví jedinci. Dvoubodové křížení (viz obr. 1.3b) spočívá v rozdělení jedinců na tři části. Pár si vymění prostřední část. Operátor uniformního křížení(viz obr. 1.3c) si u každé hodnoty nově vznikajícího jedince náhodně určí, jestli použije hodnotu alely z prvního rodičovského chromozomu nebo z druhého. (a) Jednobodové křížení (b) Dvoubodové křížení (c) Uniformní křížení 8

13 Problémy Běhy evoluce se často setkávají s neoptimálním nastavením parametrů, operátorů a všech dalších částí, které ovlivňují výpočet. Častým problémem bývá uváznutí v lokálním extrému, nebo-li příliš rychlá konvergence nebo naopak nedostatečné přiblížení se k optimálnímu řešení. Na problémy se nemusíme nutně dívat jen z pohledu prohledávání a jeho způsobu. Můžeme využívat i částečně biologický pohled a zabývat se mírou obměny genetického materiálu v populacích. Všechny problémy evoluce se paradoxně nemusí týkat jen prohledávání, při použití této metody, třeba na trénování neuronových sítí, je potřeba odhadnout také správnou míru doby učení. Je zde riziko přeučení modelu na konkrétní vstupní data, což je nežádoucí jev. Hybridní genetické algoritmy Vznik hybridních genetických algoritmů spočívá v obohacení genetického algoritmu o další vrstvu lokálního prohledávání[42]. Evoluce, v tomto případě, nemusí vytvářet řešení vstupního problému, ale jen vstup pro další algoritmus lokálního prohledávání. Výhodou této úpravy je uspíšení konvergence evolučního algoritmu pro velké prostory řešení. Po vytvoření nové generace, použitím genetických operátorů(selekce, křížení, mutace) a ohodnocení pro každého jedince z populace, následuje krok lokálního prohledávání. Ohodnocení jedinci, úspešně vylepšení lokálním prohledáváním, nahrazují svého předka v aktuální populaci. Vytváří se nová populace, která vstupuje do dalšího běhu evolučního hybridního algoritmu. Jednou z největších předností evolučních algoritmů je jejich univerzálnost a robustnost a schopnost procházet prostor řešení bez nutnosti vstupnímu problému příliš rozumět. V extrému si vystačíme se schopností vyhodnotit ohodnocovací funkci. Lokální prohledávání je se znalostí konkrétní problematiky spojeno mnohem více. Nejčastěji se v rámci lokálního prohledávání využívají triky z funkčních heuristik. Hybridní genetické algoritmy, zde uvádíme jako rozšíření výše popisovaného evolučního algoritmu. Funkční nadstavbu lokálního prohledávání spíš vnímejme jako alternativní přístup k Darwinovské evoluční teorii. Možnost geneticky předávat potomkům znalosti získané za svého života umožňuje teorie Lamarcka[30]. Snahu posuzovat řešení z pohledu jeho potenciálu se adaptovat, přinesla naopak teorie Baldwina[4]. Myšlenka kalkulovat s jedincem jako s mezivýsledkem přináší prostor pro mnohá vylepšení[17] efektivity výpočtu. Jako příklad si uvedeme třeba odhady smysluplnosti řešení na základě výsledků sousedů. Paralelizace genetických algoritmů U paralelních genetických algoritmů definujeme pojem kmen. Kmen představuje populaci jedinců. S myšlenkou vícekmenových genetických algoritmů přišel 9

14 Grefenstette v roce 1981[23]. Princip spočívá v rozdělení populace jednoho algoritmu do samostatných podkmenů. Každý podkmen samostatně vyvíjí jeden genetický algoritmus. Lokální operátory berou v úvahu jedince jen v rámci svého podkmene. Při definici podkmenů rozlišujeme mezi hrubě dělenými a jemně dělenými algoritmy. Klíčový parametr je velikost populace. Možné přístupy k paralelizaci si detailně přiblížíme v následujících kapitolách (viz kapitola 2), techniky popíšeme na úrovni modelů paralelizace a distribuce. 10

15 Další metody V předcházející části jsme si představili evoluční algoritmy a snažili jsme se nastínit aspoň základní triky, jakými docílit, aby jejich konkrétní implementace představovala optimální přístup pro řešení konkrétního problému. Ne vždy ale platí, že by evoluční algoritmy dosahovaly nejlepších výsledků. Ve zbytku kapitoly si představíme další pravděpodobnostní heuristiky. Zaměříme se na obecné algoritmy, které mají šanci najít využití v heterogenním ostrovním modelu vedle evoluce. Hill-climbing Algoritmus hill-climbing[11] se standardně představuje jako maximalizační algoritmus. Populaci tvoří jeden aktuálně vyvíjený jedinec, který je na začátku zadán nebo vygenerován. Ten se v každé generací expanduje. Hill-climbing končí, když žádný soused není lepší než aktuální řešení. V každé iteraci se projdou všichni sousedé aktuálně vyvíjeného jedince. Soused, který se nejvíce blíží k požadovanému řešení, se stává aktuálně vyvíjeným jedincem. Algoritmus tedy v každém kroku hledá a následně vybírá směr nejstrmějšího stoupání. Nejzřejmější nevýhodou tohoto algoritmu je možnost uváznutí v lokálním extrému. Algoritmus ve své základní podobě nemá šanci se z lokálního extrému vymanit. Tento problém se aspoň částečně minimalizuje opakovaným spouštěním algoritmu z různých počátečních pozic. Další hrozbu představují plošiny. V prostorech s nulovým stoupáním je algoritmus ztracen. Absence aktuální šance na zlepšení interpretuje jako nalezení extrému. Při implementaci hill-climbing algoritmu přichází nutnost vyřešit problém zjišťování sousedů jednotlivých řešení. U spojitého prostoru řešení, na rozdíl od diskrétního, vybrání nejvhodnějšího souseda nejde provést. Omezenou šanci přináší gradientní algoritmus, který předpokládá, že máme parciální derivace prostoru řešení. Možnost vypočtení gradientu v každém bodě přináší vyjádření přesného vektoru směru největšího zlepšení. U diskrétního prostoru řešení je nutné vymyslet způsob, jakým vybírat množinu sousedů. Možnost spočítat množinu sousedů nemusí být vždy dostatečná pro reálné využití. Řešení těchto potíží s určováním sousedů přináší právě stochastický hill-climbing. Stochastický Hill-climbing Stochastický hill-climbing neporovnává všechny sousedy aktuálního řešení a nehledá nejlepšího z nich, ale vybírá náhodného jednoho souseda. Na základě zlepšení, které přináší takto vybrané řešení, se spočítá pravděpodobnost přijetí daného jedince. Pokud se tak nestane, náhodně se vybírá další soused dokud algoritmus nepřijme nové aktuálně vyvíjené řešení. Samostatný stochastický algoritmus[43] často dnes vnímáme jako nástroj pro porovnání efektivity evolučních algoritmů. 11

16 Random search Random search patří do skupiny numerických optimalizačních metod, autorství je přičítáno L.A. Rastriginovi.[37]. Algoritmus v každé iteraci náhodně hledá nové řešení. Takto náhodně vygenerovaný jedinec se porovná s doposud nejlepším nalezeným řešením. Pokud je nový jedinec lepší, nejlepší doposavad nalezený je aktualizován. Algoritmus nevyžaduje spojitý ani diferencovatelný prostor řešení. Simulované žíhání Simulované žíhání bylo poprvé popsáno Scottem Kirkpatrickem[39] v roce Idea čerpá inspiraci v žíhání v metalurgii. Technika využívá teplo s postupem řízeného chlazení ke zvětšování velikosti krystalů a snižování jejich vad. Metoda(vizalg.1)pracujesjednímaktivnímjedincem.Tensealenevždycky nahrazuje lepším jedincem. Žíháním, nebo-li přijímáním i horších řešení se algoritmus snaží bránit uváznutí v lokálním extrému. Algorithm 1 Simulated annealing algorithm 1:proceduresolve(Individual individual 0,int temperature 0 ) 2: longk=0; 3: Individualindividual=individual 0 ; 4: inttemperature=temperature 0 ; 5: while (k<k m )do 6: Individual candidate = getneighbour(individual); 7: doublep=g((fitness(individual)-fitness(individual 0 ))/T); 8: if (random() <=p) then 9: individual=individual 0 ; 10: k++; 11: temperature=h(temperature 0,k); g(x) = 1 1+exp( x) h(temperature 0, k) = temperature 0 log 2 (k +2) Horší řešení jsou přijímána s určitou pravděpodobností a ta klesá v závislosti na teplotě. S každou další generací tedy pravděpodobnost přijetí horšího řešení klesá. Pokud ale nejsme spokojeni s výsledkem můžeme teplotu i zvýšit a pak znova ochlazovat. Pravděpodobnost přijetí nového výsledku určuje funkce g(x), míru ochlazení funkce h(x). Typy simulovaného žíhání se liší právě v definici těchto funkcí. Aspirační kritérium, nebo-li mechanismus přijímání nového aktuálního jedince zajišťuje algoritmu možnost přijmout i horší řešení. Díky tomuto konceptu má výpočet šanci se vymanit z lokálního optima. 12

17 Tabu search Algoritmus tabu search byl poprvé publikován v roce 1986[21]. Jeho autor je Fred W. Glover. Rozšířil klasický Hill climbing algoritmus o paměťovou strukturu. Paměť se dělí na krátkodobou a dlouhodobou. Krátkodobá slouží k uchování dříve navštívených oblastí a využívá se jako prevence proti zacyklení a to díky zákazu těchto transformací. Dlouhodobá paměť je další rozšíření, které obsahuje informace o transformacích, které byly často použity. Ty jsou pak penalizovány a tím se zabraňuje opakování. Diferenciální evoluce S diferenciální evolucí, jako postupem k evolučnímu hledání minima v aplikaci na multimodální funkce, přišli koncem devadesátých let Rainer Storn a Kenneth Price[41]. Tento algoritmus(viz alg. 2) se ukazuje jako velmi úspěšný při optimalizacifunkcízr n dor. Jedinec je reprezentován jako vektor reálných čísel a využívá se speciální typ mutace. V rámci mutace jedince jsou vybráni tři náhodní jedinci. Z této trojice je vytvořen nový jedinec. Provádí se rozdíl dvou vektorů po složkách, ten je pronásobený faktorem a následně přičtený ke třetímu vektoru. Pro křížení se používá uniformní křížení. Takto vzniklý jedinec nahrazuje mutovaného jedince vpřípadě,žejejehofitnesslepší. Algorithm 2 Differential evolution algorithm 1: procedure solve() 2: double CROSS RATE = 0.5; 3: doublef=1; 4: List<Individual> population = generate(pop SIZE); 5: longk=0; 6: while (k<k m )do 7: k++; 8: inti=0; 9: while (i<popsize)do 10: i++; 11: Individual original = population.get(randomindex0); 12: 13: Individual indiv1 = population.get(randomindex1); 14: Individual indiv2 = population.get(randomindex2); 15: Individual indiv3 = population.get(randomindex3); 16: Individual candidate.data = 17: individual1.data + F*(individual2.data- individual3.data); 18: if (random() < CROSS RATE) then 19: candidate = uniformcrossover(original, candidate); 20: if fitness(original) < fitness(candidate)) then 21: population.remove(original); population.add(candidate); return getthebest(population); 13

18 Variant diferenciální evoluce existuje mnohem více[14], většinou se liší v operátorech. Při mutaci se jako kandidát může využívat nejlepší jedinec z populace. Existuje i varianta, kdy se nepřičítá rozdíl jedné dvojice jedinců, ale rozdíl dvou dvojic jedinců. Výhodou tohoto algoritmu je, že nepotřebuje další operátory a že je v něm skrytá adaptabilita intenzity mutace. Čím jsou si jedinci více podobní, tím se agresivita mutace snižuje. Brute Force(Hrubá síla) Metoda hrubé síly je založená na systematickém procházení všech možných kombinací. Algoritmus si pamatuje nejlepší nalezené řešení a pozici konce prostoru, který už prohledal. Začíná pracovat s nultým řešením určeným nejčastěji na základě reprezentace. V každé iteraci generuje metoda další řešení, pokud je lepší, než všechny doposud nalezené, tak je prohlášeno za aktuálně nejlepší. Algoritmus Brute Force zde neuvádíme jen jako naivní zavrženíhodný způsob řešení těžkých problémů, ale jako metodu lokálního prohledávání. V okamžiku, kdy hrubou silou neprocházíme celou množinu řešení, ale jen prostory okolo lokálních extrémů ve snaze najít globální extrém, může mít i tato metoda v ostrovních modelech využití. 14

19 2. Ostrovní modely V následující kapitole si popíšeme princip fungování základních modelů, které slouží pro paralelizaci a distribuci evolučních algoritmů. Popisujeme paralelizaci z pohledu oddělené paměti jednotlivých uzlů. Farmářský model Farmářský model[9],(viz obr. 2.1a) představuje paralelní verzi sekvenčního evolučního algoritmu, centralizující logiku celého výpočtu na jednom master uzlu. Paralelizace spočívá v tom, že část výpočtu je delegována na ostatní slave uzly, které pouze vykonávají, co jim centrální uzel nařídí. Z pohledu návrhových vzorů se jedná o klasickou master/slave architekturu. Její nevýhody jsou v závislosti na jednom centrálním prvku. Populace je jedna a je centralizovaná na master uzlu. Jádro algoritmu řídí celou evoluci a rozděluje práci ve formě podúloh jednotlivým slave nodům. Master provádí inicializaci, test na konec algoritmu, selekci a pak distribuci. Jedna podúloha představuje požadavek na vytvoření potomků pro poslaný pár jedinců za pomoci křížení a mutace. Nově vzniklé jedince slave uzel ohodnotí a pošle včetně výsledku fitness zpět mastru. Master z obdržených výsledků vytvoří novou populaci a opakuje cyklus dokud není splněna ukončovací podmínka. Tento model je výhodný pro řešení problémů, kde právě provedení podúlohy obnášející provedení jednoho křížení a mutace a vypočítání fitness trvá netriviálně dlouho. Tato situace většinou nastává v případě, že je použita nepřímá reprezentace jedinců. Dekódování je pak netriviální operace, která může být spojená i se složitou transformací jedince. Bylo by krajně neekonomické distribuovat výpočet, pokud by zpracování této podúlohy bylo srovnatelně časově náročné s komunikací potřebnou pro delegaci práce a přenos dat. Migrační(ostrovní) model Migrační model[28] je založen na myšlence života několika izolovaných paralelně se vyvíjejících evolucí. Jednotlivé evoluce si můžeme představit jako ostrovy (viz obr. 2.1b), kterým brání přirozená bariéra v globální selekci při rozmnožování. Paralelně prováděné smyčky evolučních algoritmů jsou úplně stejné, jako základní evoluční algoritmus, jsou obohaceny pouze o jeden krok a to migraci. Ob určitý, klidně i náhodný počet generací evoluce, se provádí přestěhování několika jedinců na sousední ostrovy. Ideu oddělených populací, které si čas od času vymění několik jedinců, má za cíl reprezentovat právě tento model. Otázkou je, jakým způsobem vhodně zvolit sousedské vztahy a periodu provádění migrace[44]. Optimální zodpovězení těchto otázek úzce souvisí se znalostí 15

20 typu počítaného problému, rychlostí konvergence jednotlivých populací a tudíž potřebou šířit genetický materiál napříč ostrovy. Migrační modely umožňují použít na každém ostrově odlišnou selekci i operátory křížení a mutace. Teoreticky by si ostrovy mohly trošku upravit i ohodnocovací funkci, i když z pohledu koncepce snahy o dosažení společného cíle tato možnost nenachází přímočaré uplatnění. (a) Farmářský model (b) Migrační model Celulární(difuzní) model Základem celulárního modelu(viz obr. 2.2) je idea spojit fyzické jádro CPU právě s jedním jedincem v globální distribuované populaci. Jméno modelu přinesl právě způsob, jakým se prolínají a šíří vypočtení jedinci jednoho ostrovu k sousedům. Oblasti, kam jádro CPU může odeslat svoje výsledky jsou omezeny pomyslnou kružnicí. Poloměr kružnice vnímejme jako parametr. Všichni jedinci jsou v tomto modelu aktivní. Model se skládá tedy opět z několika paralelně běžících evolucí, s rozdílem, že v každé subpopulaci se nachází pouze jeden jedinec a jeho sousedé. Partnera pro křížení si jedinec vždy vybírá mezi svými sousedy. Definice sousedů je prostředek, jak ovlivnit možnost širokého výběru partnera pro křížení. Často se používají dvoudimenzionální sousedské vztahy se čtyřmi nebo osmi sousedy. Výsledky se nemusí odesílat všem sousedům, existují i varianty, kdy se vždy vybere jen jeden ze sousedů. Předmětem dynamizace nemusí být jen volba sousedů, ale i struktura celé topologie modelu[2]. Obrázek 2.2: Celulární model 16

21 Migrování jedinců Ve snaze zefektivnit distribuovaný výpočet, byla vymyšlena spousta migračních algoritmů. Obecně se tyto algoritmy dělí podle způsobu výběru migrovaného jedince a okamžiku, kdy se migrace provádí. Experimentálně bylo ověřeno, že příliš nezáleží na množství vyměněných jedinců. Dominantní faktor ovlivňující výsledek celého modelu představuje interval migrace. Přílišná migrace vede ke ztrátě globální rozmanitosti, příliš řídká zhoršuje výkon[40]. Hierarchické modely Hierarchické paralelní modely vznikly jako víceúrovňová kombinace předchozích ostrovních modelů. Vznik hierarchie může být motivován fyzickým oddělením výpočetních jader nebo snahou zredukovat komunikaci mezi jádry. Se základní myšlenkou přišel Grefenstette v roce 1981[23]. Využít Migrační ostrovní model, ve kterém se nachází v nějaké formě paralelní evoluční algoritmus. Varianty jsou celkem tři. V horní hierarchii migrační model a v dolní migrační, farmářský(viz obr. 2.3a) nebo celulární(viz obr. 2.3b). S Hierarchickým Migračním modelem přišel Gruau v roce 1994[24]. Populace je na každém ostrově rozprostřena do 2D matice. Migraci prováděl v pevně daných intervalech. Jelikož se v následujících kapitolách budeme zabývat návrhem nového distribuovaného modelu, bude nás zajímat otázka, jakým způsobem ideálně navrhovat hierarchické paralelní modely tak, aby byly co nejefektivnější. Obecně platí, že s návrhemmodelubysemělozačítvhorníhierarchiiapodletypuproblémunavrhovat spodní hierarchii[10]. Zajímavá je i problematika určení optimálního počtu ostrovů v horní hierarchii a počtu jader v jednotlivých celcích spodní hierarchie. Experimentálně se ukazuje, že největšího zrychlení se pokaždé dosahuje při jiném rozvržení zdrojů. (a) Hierarchický farmářský model (b) Hierarchický celulární model 17

22 3. Základní typy problémů V této kapitole zadefinujeme základní typy problémů, které budeme používat pro otestování nového heterogenního ostrovního modelu. Uvedeme jak spojité, tak kombinatorické optimalizace, využívající různou reprezentaci řešení. Problém obchodního cestujícího Jako první představíme problém obchodního cestujícího, který jako první definoval Gaspard Monge[20] v roce Zadefinován byl takzvaný cestovní problém v aplikaci pohybu molekul[33]. Problém patří do třídy NP-úplných problémů. Jedna věc je definice problému, druhá je použitá metrika. Právě v metrikách se liší jednotlivé typy problému obchodního cestujícího. My budeme uvažovat pouze Eukleidovskou metriku. Definice:JedánamnožinaměstC={c 1,...,c n },vzdálenostd(c i, c j ) Npro každédvěměsta c i, c j CapřirozenéčísloB. Problém: Existuje cyklus, který navštíví každé město právě jednou a jehož délka nepřesáhneb?tj.existujepermutace π : {1,...,n} {1,...,n}taková,že ( n 1 ) i=1 d(c π(i),c π(i+1) ) +d(c π(n), c π(1) ) B. Při tvorbě testů budeme uvažovat optimalizační verzi problému. Budeme se snažit minimalizovat vzdálenost B. Reprezentace Jak je již zmíněno v definici, pro reprezentaci řešení problému obchodního cestujícího se nejvíce hodí permutace. Nad touto reprezentací budeme uvažovat operátory, které budeme používat. Ohodnocení Fitness funkce se standardně volí jako délka cesty, kterou by obchodní cestující pro dané řešení nacestoval. Operátory Jako nejjednodušší stochastický operátor pro úpravu řešení reprezentovaného permutací se nabízí operátor 2-swap, který prohazuje dvě čísla v permutaci. Veliké popularitě se těší operátor 2-opt[12]. Operátor náhodně vybere dvě města. Dva určující body rozdělující cestu obchodního cestujícího na dva úseky. Podstatou operátoru je výběr kratší varianty ze dvou možných způsobů spojení těchto dvou částí celé cesty. Na následujícím obrázku(viz obr. 3.1) můžeme vidět implementaci operátoru 2-opt pro permutaci. Pořadí měst ve vybraném úseku se obrací a otočená cesta se připojuje ke zbytku permutace. Experimentálně se ukazuje, že operátor se 18

23 střetává se smyčkami v cestě a rozvíjí je. Kromě 2-opt operátoru existují varianty 3-opt i 4-opt[31]. Obrázek 3.1: Operátor 2-opt Bin packing problém Dalším NP-úplným problémem, který budeme využívat pro testování nového modelu se nazývá bin packing problém. Jedná se spíše o skupinu problémů, které sdílejí společnou myšlenku umisťování objektů do košů. Definici vytvořil Leonid Kantorovič[32], který za příspěvek k teorii optimální alokace zdrojů obdržel cenu Švédské národní banky za rozvoj ekonomické vědy na památku Alfreda Nobela. Definice:Jedánamnožinapředmětů Uaskaždýmpředmětemu Ujeasociována velikost s(u), což je racionální číslo z intervalu <0, 1>. Přípustné řešení představujerozdělenípředmětůdodisjunktníchmnožin(košů)u 1,...U m,prokteré platí, že [ ] ( i [1,...,m]) u U i s(u) 1. Cílem je minimalizovat počet košů m. Heuristiky Pro libovolnou heuristiku, která se postupně snaží vkládat objekty do částečně zaplněných košů, existuje pevný aproximační poměr. Intuitivně jde dokázat ǫ = 1 2.Vycházísezpozorování,žeménějakzpolovinyplný,můžebýtprázdnýpouze jeden koš. Základní heuristiku, představuje postupné vkládání setříděných objektů. Začít velkými a malé vkládat až nakonec. Jako příklady způsobů dekódování si uvedeme NextFitaFirstFit[18].NextFitvkládáobjektydoposledníhokoše,FirstFit zkouší vložit objekt postupně do všech košů. Pokud se vložení nepodaří, oba dva algoritmy přidají nový koš. (a) Operátor NextFit (b) Operátor FirstFit 19

24 Reprezentace, operátory, ohodnocení Pro reprezentaci se nejčastěji používá permutace. Základní operátor, který se nabízí, představuje jednoduchý posun(viz obr. 3.3). Náhodně vybereme jednu alelu, nebo-li jeden objekt a přesuneme ho na konec permutace. Ideově jde o narušení špatné závislosti po sobě následujících objektů. Také se nabízí různá prohazování hodnot permutace. Ohodnocení určuje počet použitých košů. U posledního koše se může do ohodnocení započítávat jen poměr využité části koše. Obrázek 3.3: Operátor SimpleShift Další varianty problému Kromě jednodimenzionálního výše zadefinovaného problému, existují i vícerozměrné typy problémů. U nich se při nepřímém kódování také využívá reprezentace pomocí permutace. Používají se i grafové reprezentace nebo pozicování. Další obvyklé dělení problematiky přinesly způsoby možného rozřezání umístěných objektů v koších. V aplikaci dřevo-zpracujícího průmyslu rozlišujeme třeba gilotinovatelnost nebo-li rozřezatelnost příčnými řezy nebo i semi-gilotinovatelnost [3]. Strojové učení Pod problémem strojového učení si můžeme představit spoustu aplikací. My se budeme v první řadě zajímat o problém klasifikace dat. Klasifikací nazýváme problém, kdy pro prvky z množiny pozorování máme určit do jaké množiny dat patří. Vstupní data rozdělíme na trénovací, testovací a validační a na základě nich vytvoříme model(viz obr. 3.4). Model pak používáme jako něco co určuje třídu pro vstupní pozorování. Obrázek 3.4: Strojové učení- klasifikace 20

25 Reprezentace a ohodnocení U strojového učení si musíme první položit otázku, co budeme chtít reprezentovat jako řešení. Přirozeně se nabízí uchovávat naučený model, jehož reprezentace bývá závislá na metodě učení. Jako schůdnější alternativu uvedeme reprezentaci pouhého jména metody a jejích parametrů. Model si z těchto hodnot můžeme znova natrénovat. Tvorbu operátorů, pro úpravu specifické reprezentace modelu, tak můžeme navíc nahradit operátory modifikující hodnoty parametrů metody strojového učení. Spojité optimalizace Tuto testovací úlohu nazýváme možná trochu obecně spojitou optimalizací. Pod pojmem optimalizace si představujeme hledání hodnot stavových proměnných nebo-li parametrů, které zajistí optimální chování modelu. Spojitou optimalizací myslíme minimalizaci nebo maximalizaci funkce v prostoru reálných parametrů. Předpokládáme tedy, že funkce je definovaná na intervalu, který odpovídá prohledávanému prostoru řešení. Definice:Jedánadimenze n,funkcef(x),kteráprokaždýbodx={x 1,...,x n } vrátí funkční hodnotu f(x). Problém: Najít takový bod x který je maximem(minimem) f(x). Gradientní přístupy U diferencovatelných funkcí může být pro efektivní prohledávání využita hodnota gradientu. Diferenciály v tomto případě určují přesně směr nejlepšího zlepšení. Funkci budeme vnímat jako Black Box, nebo-li černou skříňku, objekt s definovanými vstupy a výstupy, jehož způsob vnitřního fungování neznáme. Tudíž gradient funkce nemáme k dispozici. Stochastickým procházením podmnožiny okolí aktuálního řešení můžeme tuto metodu simulovat. Reprezentace a ohodnocení Pro reprezentaci řešení spojité optimalizace se výlučně používá pole hodnot odpovídající seznamu souřadnic. Funkční hodnotě funkce odpovídá ohodnocení. Body mimo definiční obor se buď nesmí objevit nebo jsou ohodnoceny maximálně negativně. Operátory Operátor RandomMove(viz obr. 3.5a) nebo-li základní operátor, představující posun bodu o náhodně vygenerovanou vzdálenost v jedné dimenzi. Pokud kombinujeme více řešení, nabízí se možnost kombinace nebo transformace souřadnic. Jako příklad si uvedeme operátor, který nazýváme RandomlyIntoTheMiddle(viz obr. 3.5b), umisťující nové řešení do prostoru mezi danými řešeními. 21

26 (a) Operátor RandomMove (b) Oper. RandomlyIntoTheMiddle Problém minimálního vrcholového pokrytí Jako reprezentanta grafových optimalizačních problémů uvádíme NP-úplný problém vrcholového pokrytí. Definice: Je dán graf G. Podmnožinu jeho vrcholů nazýváme vrcholové pokrytí grafupokudkaždáhranazgjeincidentníaspoňsjednímvrcholemzc. Cílem je minimalizovat velikost množiny C. Reprezentace a ohodnocení Vrcholové pokrytí se nejpřímočařeji reprezentuje jako podmnožina vrcholů vstupního grafu. Ohodnocení představuje velikost této množiny. 22

27 4. Související práce O paralelizaci evolučních algoritmů, ostrovních modelech i heterogenních ostrovních modelech existuje spousta publikací. Heterogenita byla představována na mnohem konzervativnější úrovni. Rozdílné parametry V případě, že heterogenitu chápeme pouze na úrovni různorodosti parametrů nejsou zásahy do infrastruktury výpočetních modelů příliš drastické. Se zajímavým přístupem na parametrech založené implementace heterogenního modelu přišli Yiyuan Gong a Alex Fukunaga(2011)[22]. Jako alternativu k ručnímu ladění parametrů představili adaptabilní přístup. Jednoduchá strategie přidělování náhodných hodnot parametrům velikosti populace, míře mutace, míře křížení pro každé CPU jádro. Výsledky testů ukazují, že adaptivita jednotlivých metod si dokáže upravit parametry tak, že jsou srovnatelné s homogenními ideálně parametrizovanými modely. Rozdílné metody Hetorogenními modely se v aplikaci multikriteriální optimalizace zabýval Martin Pilát.[34]. Navrhl nový algoritmus MOGASOLS(Multiobjective Genetic Algorithm with Single Objective Local Search) kombinující vícekriteriální genetický algoritmus(moga) s jedno-kriteriálním genetickým algoritmem(soga). Vznikl tak skutečně heterogenní model, kombinující rozdílné metody. Základní myšlenkou je paralelizace MOGA metody, protože je tato metoda výpočetně časově náročná, zkoušeli paralelně s ní spustit méně časově náročnou metodu SOGA. Metody MOGA, SOGA nejsou vlastně metody, ale jen přístupy. Testovány byly algoritmy NSGA-II[15] a IBEA[46] na několika testech. Obrázek 4.1: Schéma komunikační topologie MOGASOLS Publikace demonstruje, že výsledky jsou u většiny testů lepší, když se souběžně s MOGA metodami ve výpočtu nachází i metoda SOGA(viz obr. 4.1). Implementovaný výpočetní prostředek obsahuje dva druhy metod a tudíž je prezentován jako heterogenní ostrovní model. 23

28 5. Multiagentní systémy Z definice modelů i ze zkušeností jiných již víme, že heterogenita modelu přináší na metody požadavek schopnosti pracovat s mnohem obecnějším prostředím. Klíčová je schopnost samostatně plnit úkoly v rámci svých možností. V této kapitole budeme hledat inspiraci v oblasti multiagentních systémů. Pohled do historie Vznik multiagentních systémů je úzce spojen s výzkumem vedeným v 70. letechvoblastiuměléinteligence.bylotovdobě,kdyselidézačalizabývatjakým způsobem navrhovat distribuované inteligentní systémy, složené z oddělených jednotek schopných samostatně řešit problémy. Agent Ve snaze zadefinovat agenta bylo vytvořeno za dobu existence vědní disciplíny umělé inteligence mnoho definic. Všechny definice se ale shodují v tom, že se jedná o počítačový systém schopný pracovat v zastoupení svého uživatele, kde klíčovým prvkem je výběr optimální akce pro rozpoznaný jev. Reaktivní agent Jako učebnicový příklad bývá zmiňován reaktivní agent. Princip sepsal Rodney Brooks(1985)[8] a jeho definice našla uplatnění v oblasti autonomní robotiky a real-time systémů. Jedná se o agenta, který má pevně omezenou množinu jevů. Změna prostředí, detekovaná vjemem, bývá gramatikou přímo mapována na konkrétní jev. Přijetí vjemu zároveň přináší změnu stavu uvnitř agenta. Na základě vlastního stavu a odvozeného jevu bývá podle gramatiky vybrána akce. Gramatiku si v tomto případě představujeme jako neměnný popis chování, pevně zadrátovaný uvnitř agenta. Speciálním případem reaktivního agenta je čistě reaktivní agent, který mapuje jevy přímo na akce. Jako příklad můžeme zmínit třeba termostat. Autonomní agent Autonomní agent, podle definice Michala Wooldridge[45], je agent svobodný, takový, který rozhoduje o svých akcích sám. Člověk mu jednou vyspecifikuje jeho úkolasmyslexistenceaagentodtédobyjižfungujebezinterakcesčlověkem. Agentsisámneurčujecíle,alejenaněmvolbapodcílů.Základnímyšlenkouje delegování práce a zodpovědnosti za správnou volbu podcílů. Učící se agenti Od architektury agentů, řídícími se pouze reflexy, jednoduše doputujeme k návrhu agenta vytvářející si model světa okolo něj. Ten dává možnost širšího 24

29 rozlišeníjevů.pokudmámítagentsvoboduamásechovatracionálněmusímít i nějaký cíl. Základní změnou v koncepci u agentů s cílem je zavedení uvažování o budoucnosti. Speciální třídu tvoří učící se agenti. Obecně řečeno jsou to systémy, které se nespoléhají pouze na postupy dané tvůrcem agenta. Učící se agent může v základu vycházet z jednoduchého modelu, který mu zajišťuje jen pár schopností. Model může být tvořen například gramatikou, neuronovou sítí nebo množinou formulí.učícíseagentseodjinýchlišívtom,žesesnažísitentomodelvyvíjet. Pro otestování vylepšeného modelu si agent sám na sobě musí ověřit zlepšení schopnostiřešitproblémy.vpřípadě,žesiověří,žehonovýmodelposunekjeho cílům rychleji, tak si změnu přijme za vlastní. Ontologie Vzájemné oddělení autonomních agentů vyžaduje nutnost existence komunikačního prostředku. Zprávy, koncipované jako schéma entit, které si agenti vyměňují, nazýváme ontologie. První definici ontologie[25] provedl Thomas Gruber v roce Motivací bylo nalezení způsobu, jakým formalizovat objekty, koncepty a elementy včetně jejich vzájemných vztahů v konkrétní oblasti zájmu. Cílem byla snaha o efektivní návrh struktur pro ukládání, manipulaci a zpracování informací. V multiagentních světech, tak i třeba v expertních systémech, je optimální prostředek na popis struktur předpokládající specifické background knowledges nebo-li znalosti jedné konkrétní problematiky. Zároveň je potřeba si uvědomit, že standardizace všeho do podoby jednoho objektivně pravdivého pohledu na svět je možná jen v případě existence jednoho všepojímajícího společného zájmu. Z podstaty možné existence sobeckých agentů vyplývá pro návrháře nutnost být smířen s protichůdnými cíli a hodnotovými systémy agentů. Jakýkoli boj proti tomuto faktu, by byl izomorfní ke snaze omezit svobodu a míru vlastní adaptivnosti. Nezbývá než ontologie navrhovat jako objekty, které budou agenti schopni používat nezávisle na pohledu odesílatele. Tento přístup klade na agenty povinnost ochoty hledat v obecných ontologiích právě důležité entity z domény jejich působnosti. Komunikační protokoly Definice ontologií spočívá z pohledu filozofie ve společné konceptualizaci popisu věcí. Z hlediska informatiky se jedná o společný popis datových struktur s důrazem na reprezentaci strojově čitelných znalostí. Samotná schopnost reprezentovat informace ale nezajišťuje interoperabilitu jednotlivých celků v doméně informací. Jako prostředek pro interoperabilitu založenou na sémantickém mapovaní se navrhují komunikační protokoly. Standardizací komunikačních protokolů pro heterogenní interaktivní agentní systémy se zabýváorganizacefipa(thefoundationforintelligentphysicalagents)

30 Nejjednodušší protokol umožňující komunikaci mezi dvěma agenty představuje žádost. Jedna strana odešle takzvaný stimulus, nebo-li požadavek na nějakou službu nebo data. Druhá strana po přijetí a zpracování požadavku posílá zpět artifakt, nebo-li něco co první strana očekává. Komunikace nemusí probíhat vždy pouze mezi dvěma agenty a může být i víceúrovňová. Sofistikovanější protokoly dávají možnosti výběru nejvhodnějšího agenta pro požadovanou akci. Zesložiťování těchto mechanismů vede až k pořádání virtuálních dražeb nebo aukcí, umožňující dynamickou alokaci zdrojů. Inspirování se agenty Zobecněním výpočetního modelu získáváme širší a svobodnější prostředí pro výpočet, na druhou stranu přicházíme o spoustu jistot. Schopnost poradit si se všemi vstupy vlastně představuje adaptivitu. Dynamické přeplánovávání odpovídá vlastně procesu učení plánovače vybrat v konkrétní fázi výpočtu nejvhodnější množinu metod. Historii výpočtu budeme vnímat jako model. Multiagentní systémy nám poskytly aparát, jak klasifikovat problematiku okolo vzniku obecného heterogenního modelu. 26

31 6. Analýza systému Motivací pro vznik tohoto softwaru je vytvoření prostředku, který by umožnil otestování nového heterogenního ostrovního modelu a porovnání s homogenním modelem. V kapitole se budeme zabývat konceptuální analýzou, volbou technologie a implementační analýzou. Nový model by měl být zabstraktněním homogenních ostrovních modelů, tudíž bychom v něm měli býti schopni provést výpočet odpovídající výpočtům v homogenních ostrovních modelech. Vzniklý systém Ještěněžsepustímedoanalýzysystému,řeknemesivkrátkostiněcoosystému co jsme vytvořili. Základní představa o výsledku, nám umožní lepší vhled doprocesukterývedlkjehovzniku. Systém byl naprogramován v multiagentním frameworku, jedná se tedy o servisově orientovanou architekturu. Výpočetní metody odpovídají výpočetním agentům, kteří komunikují skrze zprávy. Jádro systému tvoří plánovač, umístěný v systémovém agentovi. Obrázek 6.1: Architektura systému Systém (viz obr. 6.1) na vstupu dostane specifikaci výpočetního modelu, vstupní problém, včetně datasetu a seznam dostupných metod. V prostředním obdélníku můžeme vidět infrastrukturu systému, plánovač i další systémoví agenti zajišťují podporu pro plánovač. Jedním z jejich hlavních úkolů je měření efektivity výpočtu jednotlivých metod. Vpravo se nacházejí distribuované nody s rozplánovanými výpočetními metodami. V následujících kapitolách se zaměříme na popis základních myšlenek a rozhodnutí, které ovlivnily návrh systému. Detaily jsou uvedeny v přiložené dokumentaci. Případy užití Zde si vytvoříme soupis a popis základních situací, ve kterých plánujeme vzniklý software používat. Převážně budeme popisovat jaké typy vstupů budeme chtít zadávat a jak budeme chtít transformovat vypočtené výsledky. 27

32 Zadat jednoduchou úlohu možnost specifikovat ostrovní model a vybrat si plánovač možnost zadat metody, které může plánovač použít Zadat složitější úlohu opakované spuštění jednoduchých úloh možnost členit úlohy na bloky úloh zadat seznam úloh do fronty Prohlížení výsledků prohlížení výsledků i mezivýsledků naskriptování vlastního modulu pro transformaci výsledků zhodnocení šíření genetického materiálu v experimentu Soupis funkčních požadavků V této části se pokusíme rozvést usecase do funkčních požadavků, které bude potřeba zapracovat do návrhu architektury systému. distribuované počítání obecných problémů pomocí EA a dalších algoritmů začlenit do výpočtu algoritmy pracující s různou velikostí populace začlenit do výpočtu algoritmy s rozdílnými možnostmi paralelizace možnost vypnout předávání jedinců mezi ostrovy možnost spuštění pouhé inicializace výpočtu bez přeplánovávání možnost přidat i nový typ problému možnost porovnávat výsledky fitness jednotlivých metod v závislosti na čase možnost zobrazit boxploty výsledků pro jednotlivé typy plánovačů Centrální bod plánovač Výpočet představuje dynamicky a adaptivně se transformující simulaci. Z logického pohledu musí existovat centrální prvek. Z centrálního místa se musí minimálně rozhodovat o odstartování a ukončení výpočtu modelu. Plánovač si představujeme jako modul schopný provádět dvě akce a to inicializaci a přeplánování. Inicializace(viz obr. 6.2a) spočívá v umístění vstupních metod na dostupná CPU jádra. Přeplánování(viz obr. 6.2b) vybírá na základě dosažených výsledků metody, které budou ze systému odstraněny a následně vybírá nové metody. Koncept architektury modelu Při návrhu výpočetního modelu si klademe otázku, jakým způsobem se inspirovat architekturami známých homogenních modelů. Předmětem práce je měření výkonu v heterogenních modelech. Jelikož se jedná o paralelní počítání, budeme 28

33 (a) Plánovač inicializace (b) Plánovač přeplánování navrhovat model běžící distribuovaně. Nebo-li budeme uvažovat shluky CPU jader oddělené vysokorychlostní sběrnicí. Model nebudeme navrhovat pro superpočítač nebo výpočetní klastr snažící se imitovat dojem homogenní mříže CPU jader, ale budeme předpokládat hardware ve formě vzájemně propojených shluků CPU jader. Vysokorychlostní sběrnice jako Infiniband sice umožňují přenos v řádech stovek gigabitů za sekundu, latence mezi výpočetními uzly zůstává omezena možnostmi materiálů. Obrázek 6.3: Vztah množiny blízkých si CPU jader a hierarchického ostrova Využijeme poznatky z teorie homogenních modelů a budeme navrhovat obecný hierarchický model. V případě potřeby můžeme horní hierarchii vynechat a mít model jednoúrovňový. Koncepčně spojíme shluky blízkých jader s rozdělením vrchní hierarchie modelu(viz obr. 6.4). Do modelu jsme také zahrnuli plánovač, který tvoří centrální prvek. Návrhem spodní vrstvy hierarchického modelu se budeme zabývat později. Obrázek 6.4: Hierarchický koncept modelu 29

34 Základní objekty Zde si popíšeme základní objekty, se kterými budeme v systému pracovat. Na následujícím obrázku můžeme vidět znázorněné závislosti. Definice problému určuje vstupní typ problému. Konkrétně jsou zde uvedeny všechny informace, které chybí v datasetu. U spojité optimalizace, zda se jedná o maximalizační nebo minimalizační problém, u Bin Packingu velikost koše. Dataset si představujeme jako načtený soubor dat pro konkrétní instanci problému. Job strukturu si představujme jako jeden základní vstup tvořený konfigurací parametrů. Metoda tvoří výpočetní prostředek, který musí být schopný zpracovat různé vstupní problémy a různé konfigurace parametrů. Výsledným řešením metody je jedinec, tranzitivně závislý přes sérii objektů. Obrázek 6.5: Základní objekty Závislost na vstupním problému Zde si můžeme uvědomit, jakým způsobem spolu souvisí konkrétní logické celky(viz obr. 6.6). Styčným bodem je reprezentace jedince, nebo-li jedno řešení vstupní úlohy. Reprezentace jedince určuje, jaké operátory, napříč algoritmy procházející stavový prostor, můžeme použít. Z této závislosti vyplývá, že snahou musí být udělat metody maximálně nezávislé na reprezentaci jedince. V opačném případě, by musely být metody naimplementovány opakovaně pro každou reprezentaci. Obrázek 6.6: Základní závislosti softwarové architektury 30

35 Jelikož jeden z funkčních požadavků je možnost přidávat i typy problémů, předpokládáme, že se může rozšiřovat i množina reprezentací jedince. U nových problémů nemůžeme předpokládat, že by si vystačily se stávajícími modely pro jedince. Varianta, kdyby se pro každou reprezentaci psaly jiné metody, tudíž nepřichází v úvahu. Metodu(viz obr. 6.7) proto rozdělíme na dvě části, na obecný výpočetní algoritmus a ProblemTool nástroj. Závislost na reprezentaci jedince a vstupním problému se bude týkat pouze ProblemTool nástroje. Obrázek 6.7: Metoda Vlastnosti ostrovních modelů Vlastnosti ostrovních modelů přinášejí i specifické problémy, se kterými je potřeba se vypořádat při měření experimentů. Zde si popíšeme potenciální překážky, se kterými se bude muset implementace nového modelu vypořádat. Nejlepší dosažený výsledek Jedna z motivací proč provádíme výpočet, je získání co možná nejkvalitnějšího výsledku vstupního problému. Je potřeba si uvědomit, že tato informace se nenachází na jednom konkrétním místě, ale je rozprostřená mezi výpočetními metodami, které si svoje výsledky posílají s určitým zpožděním. Zároveň žádná z metod negarantuje, že svoje nejlepší řešení sama zašle všem ostatním metodám. U metod sice předpokládáme snahu posílat do světa mezivýsledky svého snažení ve snaze pomoci sousedům, od propagace mezivýsledků si můžeme ale také slibovat obohacování systému o genetický materiál. Množství úspěchů Z podstaty ostrovních modelů vyplývá fakt cestování vypočtených řešení mezi metodami. Vypočtené řešení jedné metody si tak může velmi rychle přivlastnit jiná metoda a při procesu vylepšování tohoto jedince může získané řešení opět rozesílat kolem sebe a vydávat ho za svůj úspěch. Tato vlastnost systému nám nedovoluje určovat míru užitečnosti metody z jedné informace o nejlepším vytvořeném jedinci. Množství příležitostí Pokud budeme počítat úspěchy metod, měli bychom být schopni též plánovači poskytnout informaci o tom, jaké příležitosti k výsledkům metody měly, neboli reportovat, kolik časových kvant bylo metodě přiděleno. Tyto úvahy nutně 31

36 vedou k vedení historie běhu jednotlivých metod a jejich parametrů v průběhu jednoho experimentu. Takováto struktura pak plánovači dává možnost odhadnout potencionálně perspektivní metody, které nedostaly tolik příležitostí. Definice názvosloví Prohledávací algoritmus = algoritmus prohledávající stavový prostor nezávislý na reprezentaci jedince ProblemTool nástroj = nástroj pro manipulaci s jedincem závislý na reprezentaci Metoda = Prohledávací algoritmus + ProblemTool nástroj + parametry Návrh heterogenního ostrovního modelu Vylučovací metodou můžeme ihned říci, že z důvodu různých přístupů prohledávacích algoritmů inspirace farmářským modelem bude minimální. Inspirování se migračním modelem, by se v naší aplikaci na první pohled mohlo zdát velmi lákavé. Spojit definici ostrova s jedním fyzickým výpočetním strojem a vytvořit lokální autoritu, která by na tomto ostrově vládla a snažila se pozitivně ovlivňovat výpočet. Vládce ostrova by v takovém případě získal od centrálního plánovače určitá privilegia, která by lokálně mohl uplatňovat. Výpočet evolučních algoritmů by mohl být paralelizovatelný na úrovni vyhodnocování fitness funkce. Efektivita tohoto paralelizmu je podmíněna velkou populací. Jeden z funkčních požadavků na systém byla možnost používat ve výpočetním modelu obecné metody, tudíž i ty jednoduché, co pracují s jednoprvkovou populací. Tyto metody by na ostrově ale nezbývalo než spustit odděleně v několika instancích. Jako přímočařejší řešení pro návrh heterogenního modelu vychází možnost inspirace u difuzního modelu. Centrální plánovač rozplánovává jednotlivé jednojádrové metody na konkrétní fyzická CPU. Vynucení jednojádrovosti se ukazuje jako jediný možný jednotný interface, který má navíc šanci minimálně ovlivnit efektivitu výpočtu. Obrázek 6.8: Vztah metody a jádra CPU Nový model(viz obr. 6.9) bude tudíž nejvíce podobný hierarchickému celulárnímu modelu. Rozdílné metody využívající vždy po jednom CPU jádru značíme různou barvou. 32

37 Obrázek 6.9: Nový heterogenní model Definice vstupu Objekt představující jednu vstupní úlohu systému nazýváme Job strukturou. Jedná se o strukturu obsahující instanci vstupního problému, prostředků, které může plánovač použít k řešení a specifikaci výpočetního modelu. Typ plánovače je také jedním z parametrů. Dalším parametrem job struktury je počet běhů, kolikrát má být daná úloha spuštěna. Abychom byli schopni vyhodnocovat a dále zpracovávat a vzájemně porovnávat výsledky vstupních Job struktur, je potřeba zadefinovat Batch strukturu nebo-li dávku. Jedná se o množinu Job struktur a množinu Postprocessing struktur, zajišťující právě ono zpracování vypočtených výsledků. Vstup systému by navíc neměl být limitovaný pouze jednou vstupní batch strukturou, ale měl by umožňovat zadat struktur více. Definice job struktury identifikace job struktury popis početběhů ostrovnímodel definice problému + dataset plánovač včetně parametrů plánovač- ukončovací podmínka seznam prohledávacích algoritmů seznamnástrojů Definice batch struktury identifikace batch struktury popis seznam job struktur seznam postprocessing struktur 33

38 Transformace vstupní job struktury Po zadefinování vstupů systému si ukážeme jakou transformací musí struktury projít, aby mohl vzniknout výpočetní požadavek pro jednu metodu. Jednu job strukturu vnímáme jako základní kámen jedné vstupní dávky a jak již bylo popisováno, jedná se o strukturu obsahující velké množství parametrů týkajících se výpočtu. V průběhu putování struktury systémem o nějaká data přijde a zase nějaká získá. Na následujícím diagramu(viz obr. 6.10) můžeme vidět transformace, kterými struktura prochází. Datová struktura ProblemStruct, kterou vnímá jako vstup jedna výpočetní metoda, pochopitelně vychází ze struktury job, navíc musí obsahovat ještě další informace. Základem je identifikace dávky a běhu. Dále je nutné dodat, jaký nástroj má metoda používat pro řešení problému. Některé informace ze struktury job ve struktuře ProblemStruct naopak chybí, jako například, jaký plánovač má výpočet řídit. Obrázek 6.10: Transformace job struktury Popis modulu Plánovače Pokusíme se popsat modul plánovače z pohledu interakce této komponenty s okolím. V následujícím diagramu(viz obr. 6.11) představuje plánovač středobod centrálního řídícího modulu. Nalevo vidíme vstup, strukturu představující konkrétní běh jedné job struktury. Z parametrů uvnitř zadání infrastruktura plánovače získá ukončovací podmínku i implementaci plánovače. 34

39 Obrázek 6.11: Architektura plánovače Do implementace plánovače vstupují informace o dostupných prohledávacích algoritmech a ProblemTool nástrojích. Z nich se vytvoří kartérský součin a vznikne seznam dostupných metod. Implementace plánovače pak rozhodne o inicializaci všech CPU jádrech na dostupných nodech. Po umístění metod na naplánovaná jádra plánovač spustí výpočet. 35

40 Technologie Technologie by měla umožňovat přirozenou implementaci obecných metaheuristik s možností nenáročného rozšiřování o adaptabilitu a schopnost učit se. Z návrhu modulů jednoznačně vyplývá, že systém je tvořen z obecných metod, které za pomoci plánovače a vzájemné spolupráce dokáží efektivně počítat obecné problémy v heterogenním ostrovním modelu. Pro implementaci samostatně myslícího systému složeného z mnoha typů na sobě nezávislých modulů se ideálně hodí multiagentní frameworky. Volba technologie Motivací pro vznik systému je možnost porovnat různé implementace plánovačů pro různé typy problémů. V rámci zpracování výsledků nebude potřeba kalkulovat s absolutní časovou metrikou, ale vystačíme si s pouhým porovnáváním doby běhu jednotlivých plánovačů. Tato skutečnost přináší možnost uvažovat při výběru i interpretované programovací jazyky. Cílem systému není vytvořit implementaci, která by efektivně využívala hardwarových prostředků, které nabízí konkrétní hardwarová architektura nebo zoptimalizovat výpočet pro konkrétní ostrovy propojující HPC sběrnici. Pro tvorbu výkonného distribuovaného modelu se nabízí mnoho middlewarů (OpenMPI, Corba). Zajímavou technologii, která vysokoúrovňově dovoluje tvorbu samostatně myslících agentů a která poskytuje nástroje, jak nad middlewarem jednoduše zadefinovat i schopnost se adaptabilně vyvíjet, představuje framework JADE. Java Agent DEvelopment framework[6] je technologie vyvíjená italským Telecomem. Fabio Bellifemine jako projektový manager si kladl za cíl vyvinout nástroj pro řízení datové komunikace v heterogenních sítích. Jedná se o middleware, umožňující vytvářet vlastní peer-to-peer inteligentní adaptabilní agenty. Technologie umožňuje agentům dynamicky přiřazovat různá chování. Tato chování pak určují funkcionalitu agenta v konkrétní okamžik. Zároveň umožňují agentům přijímat a odesílat KQML[19] a ACL zprávy[35]. Přeplánování, nebo-li záměna metod na ostrově, by se jednoduše implementovala jako zabití starého agenta a vytvoření nového. Právě možnost koncipovat systém jako množinu samostatně oddělených agentů, zjednodušuje vývoj adaptabilního ostrovního modelu. Pro programovací jazyk Java navíc existuje spousta knihoven, které implementují vybrané problémy. Tyto argumenty vedly k rozhodnutí vybrat pro implementaci systému multiagentní framework JADE. 36

41 Množství úspěchů Z návrhu ostrovního modelu vyplývá možnost cestování vypočtených řešení mezi ostrovy, nebo-li výpočetními metodami. Vypočtené řešení jedné metody si může velmi rychle přivlastnit jiná metoda a při procesu vylepšování tohoto jedince může získané řešení opět rozesílat kolem sebe a vydávat ho za svůj úspěch. Tato vlastnost systému nám nedovoluje určovat míru užitečnosti metody z jedné informace o nejlepším vytvořeném jedinci. Ve snaze vytvořit metriku zásluh vznikl centrální prvek Monitor, který monitoruje a analyzuje genetický materiál rozesílaný v systému. Jedná se o opačný přístup, kdy se na informaci nedotazujeme, ale řešení odposloucháváme a statisticky zpracováváme. Touto metodou jsme schopni spočítat, kolikrát se metodě podařilo vytvořit řešení lepší, než bylo doposud známé. Také umíme vyjádřit různorodost a kvalitu metodou rozesílaných jedinců. Výstupem monitoringu je statistika, která slouží jako vstup pro přeplánování. Dává mu tímto možnost nahlédnout do průběhu celého výpočtu. Množství příležitostí Pokud budeme počítat úspěchy metod, měli bychom být schopni též plánovači poskytnout informaci o tom, jaké příležitosti k výsledkům metody měly, nebo-li reportovat, kolik časových kvant bylo metodě přiděleno. Tyto úvahy nutně vedou k vedení historie běhu jednotlivých metod a jejich parametrů v průběhu jednoho RunJobu. Z této struktury si pak plánovač dokáže zjistit úspěšné potencionálně perspektivní metody, které nedostaly tolik příležitostí. Implementace nového ostrovního modelu Po volbě technologie budeme o návrhu systému uvažovat nad rámec konceptuálního pohledu v rovině implementační, platformově specifické. Jako první si zadefinujeme předpoklady, ze kterých budeme vycházet. Motivací pro vznik předpokladů je nekomplikovat model více, než je nezbytně nutné. Předpoklady stejně výkonná jádra procesorů na všech nodech sdílený souborový systém Obrázek 6.12: Vztah JADE Containeru a ostrova V multiagentním světě budeme spojovat jeden ostrov(viz obr. 6.12) s JADE kontejnerem, nebo-li jednou běžící instancí systému. Jednoho agenta(viz obr. 6.13) budeme vázat s výpočetní metodou. 37

42 Obrázek 6.13: Vztah agenta a metody Na následujícím obrázku(viz obr. 6.14) vidíme implementaci heterogenního modelu v JADE frameworku. V oddělených JADE kontejnerech jsou umístěni různí výpočetní agenti. Obrázek 6.14: Implementace nového ostrovního modelu Volba metriky Základní otázkou je, jak zjistit míru přínosu agenta pro společný výpočet. Otázku odhadování možného budoucího přínosu agentů přenecháme plánovačům. Cílem volby množiny vhodných metrik je dát Plánovačům prostor právě pro tyto spekulace. Uveďme si základní ideje, které by dávaly možnost feedbacku efektivity výpočtu Plánovači. Množství příležitostí Na začátku výpočtu se snažit dát šanci každé z výpočetních metod. Metody, které nedostaly příležitost k běhu nemůžeme penalizovat za nedostatek úspěchů. Nejlepší jedinec U výpočtu, kde se vypočtená řešení ihned předávají sousedům ve snaze pomoci jim, se musí počítat s tím, že nejlepší jedinec konkrétního agenta nebude automaticky znamenat jeho nejlepší dosažený výsledek. Může se jednat o převzatý výsledek. 38

43 Poměr zásluh na výpočtu Kvalitu výsledků jedince bychom mohli uvažovat v závislosti na tom, jak moc dobré výsledky mu dodali jeho sousedé. Vzdálenost dvou jedinců od sebe Pro možnost posuzování systému z hlediska exploatace a explorace je nutné mít schopnost zadefinovat vzdálenost mezi každými dvěma jedinci. Výpočet vzdálenosti bude záviset na interní reprezentaci jedince a také na typu úlohy, kde nespojité optimalizace budou moci dosáhnout jen různě přesných odhadů. Měření zásluh jednotlivých metod Ve snaze vytvořit maximálně efektivní distribuovaný výpočet jednotlivé metody upravujeme tak, aby jednoduše přebíraly a vylepšovaly řešení ostatních výpočetních metod. Důsledkem tohoto chování systému dochází k vydávání cizích řešení za vlastní a tím pádem určení, která metoda má na distribuovaném výpočtu největší zásluhy, není jednoduchý proces. Cílem této kapitoly je rozhodnout otázku, jakým způsobem navrhnout architekturu univerzálního prostředku pro měření zásluh jednotlivých metod. Z podstaty fungování měřeného distribuovaného výpočtu můžou být nezkreslené pouze výsledky, které byly měřeny se stejnou nebo vyšší frekvencí, než je frekvence distribuce jedinců. Smyslem návrhu měřidla je nevytvořit prostředek, který by limitoval výpočetní metody. Cílem je, aby uměl měřit všechny metody bez nutnosti znát jejich frekvence odesílání jedinců, které se můžou vzájemně lišit. Jako elegantní řešení problému měření představuje vznik samostatného modulu Monitor, který v systému poslouchá, co která metoda posílá za řešení. Tyto informace pak pro každou metodu zpracovává do formy statistiky. Informací, které skrze systém proputují, je skutečně hodně a proto je potřeba je okamžitě zpracovávat. Základní hodnotu, kterou modul obsahuje je nejlepší dosažený výsledek výpočtu. Nově příchozí jedinci pochopitelně tuto informaci v případě, že jsou lepší, updatují. Počet nalezení lepšího jedince, než je aktuálně nejlepší jedinec systému, bude tvořit základní položku pro statistiku metody. Definice statistiky jedné metody počet kolikrát metoda vytvořila nejlepšího jedince počet kolikrát metoda vytvořila elitního(k-tého nejlepšího) jedince počet celkově odeslaných jedinců počet typů vytvořených jedinců průměr fitness metodou odeslaných jedinců nejlepšíjedinec 39

44 Plánovač a jeho vstupy Struktura plánovače(viz obr. 6.15) je tvořená ze třech částí, z infrastruktury plánovače, ukončovací podmínky a ze samotné implementace plánovače. Infrastrukturu plánovače vnímejme jako statickou část systému, která se nemění. Ukončovací podmínka výpočtu a konkrétní implementace plánovače, jsou určené jako parametry ve vstupní job struktuře. Obrázek 6.15: Vstupy plánovače Vstupy plánovače vnímáme jako informace, na základě kterých může proběhnout přeplánování. Jako tři základní zdroje vnímáme strukturu historie, pomocníků a rodokmenu. Historii poskytuje plánovači agent Monitor, jako soupis statistik. Ten pracuje na základě odposlouchávání výpočetních metod. Opačný přístup představuje koncept vyptávání se jednotlivých metod na míru pomoci, kterou jim přinesly žijící sousední metody v modelu. Třetí informační zdroj představuje rodokmen nejlepšího vytvořeného jedince. Ten obsahuje záznamy o počtech úprav a vylepšeních jedince od jeho vygenerování. Historie V předchozí kapitole jsme si zadefinovali statistiku vypovídající o úspěšnosti metody. Po každé iteraci plánovače systém sesbírá statistiky jednotlivých metod identifikované specifikací metody, čísla její instance a čísla ostrova. Tato data musí projít transformací do podoby hierarchie typů metod a jejich instancích nezávislých na fyzickém umístění metody v ostrovním modelu. Historií budeme nazývat soubor statistik všech typů vstupních metod napříč iteracemi plánovače. Snažíme se vytvořit strukturu historie, ze které by šly například dohledat metody, které vyprodukovaly nejvíce zlepšení, nebo největší počet genetického materiálu v průběhu několika iterací plánovače. Také budeme chtít umět určit typ metody, která nedostala příležitost k běhu po nejdelší dobu nebo dostala přiděleno nejméně strojového času. Statistika pomocníků Jako alternativní způsob měření zásluh k arbitru odposlouchávající předávané jedince v systému přináší statistika pomocníků. Základní myšlenkou je ponechat 40

45 zodpovědnost za ocenění pomoci, kterou poskytli sousedé na jednotlivých metodách. U konceptu pomocníků(viz obr. 6.16) služba zajišťuje postupné dotázání se všech metod a agregaci jejich výsledků. Obrázek 6.16: Pomocníci Mechanismus je založen na přesvědčení, že metody nevnímají své sousedy jako konkurenty, ale jako partnery. Předpokládáme, že každá výpočetní metoda si vnitřně uchovává nejlepšího, buď vypočteného nebo převzatého jedince. Pomoc od sousedů vnímáme jako obdržení lepšího jedince než metoda doposud získala. Statistika pomocníků metody je tvořena počty těchto výpomocí v závislosti na všech dostupných sousedech. Agregace statistik tvoří součet statistik po složkách, nebo-li jednotlivých metodách. Rodokmen jedince Předcházející dva přístupy se snaží odvozovat efektivitu metod od kvality jedinců, které vyslaly do světa. Jako alternativu představujeme obalování vypočtených jedinců rodokmeny a snahu vytěžit z rodokmenů nejlepších jedinců míru zásluh metod na celkovém výpočtu. Rodokmen si představujme jako datovou strukturu sloužící pro uchování informací o vývoji jedince. Způsob návrhu struktury musí zohledňovat efektivní úpravu struktury pro operace v nástroji a také prostorově nenáročnou reprezentaci, jako ontologii. Jako příklad jedné z možných implementací rodokmenu uvádíme klasickou stromovou hierarchii předků(viz obr. 6.17). Obrázek 6.17: Rodokmen strom Jedná se o strom, kde vrchol specifikuje popis metody, která vytvořila nové řešení z jedinců, jejichž rodokmeny jsou v seznamu synů. Operátor vytváří nový rodokmen s kořenem, obsahující po operaci mutace jednoho potomka, při křížení dva potomky a u diferenciální evoluce tři potomky. 41

46 Rozvržení infrastrukturních služeb do agentů Pro implementaci softwaru byl zvolen multiagentní framework ve snaze využít možnosti spojit definici metody s adaptivním agentem. Kromě metod je potřeba vytvořit i infrastrukturu a rozvrhnout ji do služeb agentů. Agenty budeme tedy dělit na výpočetní a systémové. Systémoví agenti tvoří infrastrukturu systému, zajišťují inicializaci výpočtu, transformaci a uchování výsledků. Kromě technického zázemí, zajišťují také plánování běhu jednotlivých výpočetních agentů. Agent Initiator Agent, který se na každém ostrově spouští jako první. Agent jako první vytvoří agenta Managera, lokálního vládce nad místními agenty a ve spolupráci s ním vytvoří zbylé systémové agenty. Agent Lokální Manager Ve světě agentů se jednotliví agenti mohou shlukovat do skupin. Rozdělení na tyto skupiny může korespondovat se serverovou architekturou, kde jedna skupina odpovídá jednomu stroji. Bez ohledu na volbu modelu ostrovní architektury a způsobu jakým budou části architektury odpovídat skupinám agentů se ukazuje jako vhodné, aby každá skupina agentů měla vlastní autoritu. Mezi pravomoci správce takového prostředku patří rozhodování o typu a počtu běžících agentů. Ve spolupráci s Centrálním managerem vytvářejí lokální autority optimální nástroj pro manipulaci s dostupnými zdroji a zároveň tvoří službu obstarávající standardizaci unikátní jmenné konvence. Agent Datamanager Motivací pro vytvoření tohoto agenta byla snaha o minimalizaci závislosti řadových agentů na schopnosti pracovat s technologiemi zajišťující uchování dat. Agenta z pohledu postaveného multiagentního světa můžeme vnímat jako službu, která je schopná zajišťovat předávání dat pomocí ontologických zpráv. Agent Centralmanager Jedná se o agenta řídícího celý výpočet. Obsahuje modul plánovače, který rozhoduje o způsobu inicializace ostrovního modelu a jeho následných úpravách na základě dosažených mezivýsledků. Agent Monitor Modul zajišťující monitorování a odposlouchávání všech výpočetních agentů se v multiagentním světě přirozeně reprezentuje jako služba, kterou zajišťuje agent pojmenovaný Monitor. 42

47 Obrázek 6.18: Návrh architektury služby monitoringu Na obrázku můžeme vidět ostrovní model implementovaný v multiagentním světě. Ostrovy jsou spojeny s middleware kontejnery a popisované služby se namapovaly do agentů. Můžeme zde vidět čtyři kontejnery, jeden main a tři slave. V hlavním kontejneru působí systémoví agenti, uprostřed mraku se nachází monitor, který odposlouchává komunikaci všech běžících výpočetních metod. Výrazné šipky s obálkami reprezentují výměnu jedinců v systému. Naopak mezi agentem Centrálním managerem a Monitorem probíhá komunikace už pouze na úrovni naměřených statistik. Agent výpočetní agent Výpočetní agenti představují prohledávající algoritmy pracující nad jedním CPU jádrem. Na následujícím obrázku(viz obr. 6.19) můžeme vidět dva typy příchozích zpráv a to příkazy od agenta centrálního managera a příchozí jedince od sousedních výpočetních agentů. Základním příkazem je začátek počítání. Jako vstup dostává strukturu ProblemStruct, ve které je vyspecifikován ProblemTool nástroj a zadán vstupní problém. Abychom se vyhnuli přímé závislosti jednotlivých algoritmů na reprezentaci jedince, vytvoříme nástroj, který obecné algoritmy od reprezentace odstíní. Tento nástroj budeme nazývat ProblemTool. Nástroj bude představovat prostředek pro obecný algoritmus na manipulaci s jedinci, odstiňující jejich reprezentaci i typ problému, který řeší. Rozhraní je potřeba navrhnout tak, aby bylo schopné pokrýt požadavky všech prohledávacích algoritmů. Míra efektivity operací bude závislá na reprezentaci a nezbývá než se smířit s tím, že někdy půjde operace naimplementovat jen 43

48 Obrázek 6.19: Výpočetní agent velmi neefektivně a těžkopádně. Jako příklad neoptimálně řešitelného operátoru můžeme uvést hledání sousedních jedinců u nepřímé reprezentace. Musíme počítat i se situacemi, kdy se nám nepovede efektivně vyplnit ProblemTool nástroj osvědčenými operátory. Neefektivitu takovéto metody by pak měl v heterogenních modelech řešit právě plánovač její eliminací. Definice rozhraní ProblemTool nástroje Problémem myslíme instanci konkrétního typu problému, který dostává modul Plánovač na vstupu. Aby byl obecný prohledávací algoritmus schopný počítat, musí dostat nástroj, který dá tak agentovi možnost skrze něj manipulovat s problémem a jedinci a aspoň trochu porozumět tomu, co vlastně vyvíjí. Rozhraní ProblemTool nástroje načtení souboru do struktury Dataset fitness(individual,problem) vygenerujnáhodnéhojedince(problem) vygenerujprvníhojedince(problem) vygenerujdalšíhojedince(problem,individual) vraťsouseda(problem,individual) vylepšijedince(individual)- mutace vytvořenínovéhojedince(individual,individual) vytvořenínovéhojedince(individual, individual, individual) Z hlediska návrhu modulů bychom chtěli v systému využívat algoritmy, které by byly obecné a v ideálním případě byly schopné řešit všechny typy problémů. Operátory a funkce závislé na konkrétním typu problému byly přesunuty do modulu Nástrojů. S touto myšlenkou, ale přichází i velmi praktická otázka, a to jak navrhnout rozhraní ProblemTool nástroje. První základní službu, kterou musí ProblemTool nástroj poskytovat je vygenerování náhodného jedince, který představuje řešení konkrétního problému. Bez této schopnosti není možné nagenerovat počáteční populaci evolučního algoritmu. Využití najde i u RandomSearch algoritmu. Další nepostradatelnou službou je možnost vylepšení jedince. Využití najde jak u mutace evolučního algoritmu, tak 44

49 u Hillclimbingu. Následně musíme doplnit operace vytvoření nového jedince ze dvou vstupních jedinců, což se bude hodit jako operátor křížení u evoluce, tak vytvoření nového jedince ze tří vstupních jedinců, což bude využívat diferenciální evoluce. Pro algoritmus využívající hrubou sílu musíme ještě doplnit možnost vrátit nadcházejícího jedince. A pro TabuSearch možnost vrátit sousedy aktuálního jedince. Tato funkcionalita se sice u nepřímé reprezentace individuí může těžko implementovat, ale pro dodržení konceptu existence jednoho univerzálního rozhraní, zde nemůže chybět. Využití ProblemTool nástroje u evolučního algoritmu Pro větší názornost si ukážeme jakým způsobem využívá evoluční algoritmus ProblemTool nástroj(viz obr. 6.20). Na levé straně obrázku můžeme vidět nekonečnou smyčku evolučního algoritmu, ze které se v maximální míře abstrakce volají služby plánovačem dodaného nástroje. Algoritmus je závislý pouze na abstraktním jedinci, který nezávisí na vstupním typu problému. Obrázek 6.20: Použití nástroje v evolučním algoritmu V rámci inicializace se pomocí nástroje načte vstupní dataset a vygeneruje se nultá populace. Dále můžeme vidět další tři navázání algoritmu na nástroj, a to v souvislosti s ohodnocením jedince, provedení křížení a mutace. Křížení je mapováno na vytvoření jedince ze dvou vstupních jedinců. Mutace zase na vylepšení jedince. 45