P-GRADE: Párhuzamos programok fejlesztése és

futtatása szuperszámítógépeken, klasztereken és Grid rendszereken[1]

 

Kacsuk Péter

MTA SZTAKI

kacsuk@sztaki.hu

www.lpds.sztaki.hu

 

 

 

Absztrakt

 

A SZTAKI PERL laboratóriumában több év óta folyik egy olyan párhuzamos program fejlesztő rendszer (P-GRADE) tervezése és fejlesztése, amely magas szintű grafikus eszközeivel a párhuzamos programok fejlesztésének minden lépését (szerkesztés, fordítás, hibakeresés, teljesítmény monitorozás és vizualizáció, leképezés szuperszámítógépek és klaszterek processzoraira) támogatja. A legújabb kutatási eredmények a P-GRADE futtató rendszer lehetőségeit bővítették számos olyan módszerrel (ellenőrző-pontok automatikus készítése, automatikus terhelés-kiegyenlítés, hibatűrő végrehajtás), amelyek révén a P-GRADE alatt kifejlesztett párhuzamos programok végrehajtásának hatékonysága jelentős mértékben növelhetők mind a szuperszámítógépeken és klaszterekben, mind az újabban egyre jobban terjedő Grid rendszerekben.

 

1. Bevezetés

 

A P-GRADE rendszert eredetileg párhuzamos programok fejlesztésének támogatására hozta létre a SZTAKI Párhuzamos és Elosztott Rendszerek Laboratóriuma. A Párhuzamos rendszerek fejlesztése lényegesen nehezebb és összetettebb feladat, mint a szekvenciális programoké, ezért vált szükségessé egy olyan grafikus környezet kidolgozása, melyben nem informatikus képzettségű végfelhasználók (pl. meteorológusok, kémikusok, stb.) is képesek szuperszámítógépeken és klasztereken futtatható programok kifejlesztésére. A P-GRADE rendszer eredeti formájában grafikus nyelvet, grafikus editort, előfordítót, PVM könyvtár támogatást, elosztott grafikus hibakereső rendszert, monitorozó és vizualizációs rendszert biztosít a felhasználóknak [1], [2].  A programfejlesztés interaktív módon történik az 1. ábrán látható fejlesztési ciklusnak megfelelően. A szerkesztés, fordítás és hibakeresés végrehajtása egyprocesszoros környezetben ajánlott. A teljesítményméréseket azonban már sokprocesszoros környezetben célszerű végrehajtani. Ehhez először is meg kell határozni a processzek leképezését a processzortérbe, majd a párhuzamos végrehajtás során folyamatosan mérhetjük az egyes események (pl. üzenetküldés processzek között) idejét és végül ezeket vizualizálhatjuk. Ha a teljesítmény nem kielégítő, akkor vagy az eredeti programot kell módosítani, vagy sok esetben elegendő a processzor leképezésen változtatni.

 

A fent leírt programfejlesztés eredményeképpen létrejön egy párhuzamos program, aminek végrehajtási ideje akár több napot is igénybe vehet. Egy ilyen program végrehajtására a következő lehetőségek vannak:

 

  1. Saját dedikált klaszteren történő végrehajtás
  2. Végrehajtás mások által is használt szuperszámítógépen, vagy klaszteren
  3. Végrehajtás a Gridben

 

A P-GRADE továbbfejlesztésében a fő cél az elmúlt két évben a fenti végrehajtási módok támogatása és minél hatékonyabbá tétele volt. A továbbiakban áttekintjük azokat a P-GRADE kiterjesztéseket, amik a fenti végrehajtási módokat támogatják.

 

 

1. ábra Fejlesztési ciklus P-GRADE interaktív módban

 

 

2. P-GRADE program végrehajtása dedikált klaszteren

 

Ha a felhasználó olyan szerencsés, hogy saját klaszterrel rendelkezik, amit a kifejlesztett párhuzamos program végrehajtására dedikálhat, akkor a program végrehajtása során a következő lehetőségek segítik a minél hatékonyabb végrehajtást:

 

  1. Automatikus terhelés-kiegyenlítés
  2. Automatikus hibatűrés
  3. Monitorozás és vizualizáció

 

2.1 Automatikus terhelés-kiegyenlítés

 

Sok esetben egy párhuzamos program olyan komplex, hogy viselkedési jellemzői futás közben dinamikusan változnak, azaz bizonyos processzek a végrehajtás bizonyos fázisaiban aktívabbak máskor passzívabbak. Ez azt jelenti, hogy a kezdeti processz-gép leképezés a futás során nem biztosítja a processzorok egyenletes terheltségét, ami hosszú távon a párhuzamos rendszer hatékonyságának csökkenéséhez és a párhuzamos program végrehajtási idejének jelentős növekedéséhez vezet. Ennek a jelenségnek a kiküszöbölése egy több napon, de akárcsak több órán keresztül futó program esetén is komoly megtakarítást jelent processzoridőben és teljesítményben.

 

A probléma az automatikus terhelés-kiegyenlítés módszerével oldható meg. Az ehhez szükséges eszközöket és ezek kapcsolódását a P-GRADE rendszerhez mutatja a 2. ábra. A terhelés-kiegyenlítő modul három fő részből áll:

 

  1. Monitor modul
  2. Döntési modul
  3. Migrációs modul

 

A Monitor modul bizonyos beállítható periodicitással (pl. 5 percenként) méri a dedikált klaszter processzorainak terheltségét és a mérés eredményét átadja a Döntési modulnak. Ez a mért értékek alapján megvizsgálja, hogy a klaszter processzorainak kihasználtsága mennyire volt egyenletes a mérési periódusban. Ha a terhelési szintek különbsége egy bizonyos küszöbértéket meghalad, akkor a szimulált-hűtés algoritmust felhasználva eldönti, hogy a processzek átcsoportosításával elérhető-e egyenletesebb processzor kihasználtság. Ha ez nem lehetséges, akkor engedélyezi a párhuzamos program futásának folytatását. Ha az átrendezés eredményes lehet, akkor összeállítja az átcsoportosítandó processzek listáját megadva régi és új pozíciójukat a processzortérben. Ezután elküldi ezt a listát a Migrációs modulnak. Ennek a feladata a processzek tényleges átrendezésének a megvalósítása. Az átrendezés feltétele, hogy a mérési periódus végén a processzek állapotáról egy olyan lementés, un. ellenőrző-pont készüljön, melyből a processzek aktuális állapota az esetleges átrendezés után visszaállítható és a párhuzamos program működése a megszakítási ponttól folytatható [3]. A Migrációs modul tehát a mérési periódus végén minden processzre elkészíti az ellenőrző-pontot és vár a Döntési modul döntésére. Ha ez nem kér átrendezést, akkor a Migrációs modul engedélyezi a processzek tovább futtatását az aktuálisan hozzájuk rendelt processzoron. Ha az átrendezés szükséges, akkor az átrendezési listában szereplő minden egyes processz számára a processzhez tartozó ellenőrző-pont alapján telepíti a processzt az átrendezési listán szereplő célgépre.

 

Mérésekkel igazolható, hogy az automatikus terhelés-kiegyenlítés jelentős sebességnövekedéshez vezet dinamikusan változó terhelést eredményező programok esetén, de olyankor is, ha a felhasználó helytelen kezdeti processz-gép leképezést alkalmaz. A technikai részletek iránt érdeklődő olvasok megtalálhatják az automatikus terhelés-kiegyenlítő modul részletes leírását [4]-ban.

 

 

2. ábra A P-GRADE rendszer kiterjesztése

az automatikus terhelés-kiegyenlítő (load-balancer) modullal

 

2.2 Automatikus hibatűrés

 

A klaszterek általában kevésbé megbízhatóak, mint egy szuperszámítógép, ahol a gyártók gyakorlatilag 100%-os rendelkezésre állást garantálnak. (Többek között ez az egyik oka annak, hogy a szuperszámítógépek legalább egy nagyságrenddel drágábbak, mint az azonos teljesítményű dedikált klaszterek.) Ugyanakkor, egy több napig futó program esetén igen bosszantó, és emellett az üzleti életben komoly anyagi veszteséget okozó lehet, ha a program néhány nap futás után azért áll le, mert a dedikált klaszter valamelyik gépe meghibásodott. Ennek a problémának a megoldását szintén biztosítani tudja a P-GRADE rendszer legújabb verziója.

 

A megoldás alapja ugyanúgy a ellenőrző-pont készítés, mint az automatikus terhelés kiegyenlítés esetén. A megoldás lényegében visszavezethető a fent leírt automatikus terhelés-kiegyenlítő modulra. Ha valamely gép működése leáll, azt a Monitor modul érzékeli és a mérési periódus végén ezt az információt továbbítja a Döntési modulnak a többi mért adattal együtt. A Döntési modul ebben a helyzetben kiértékeli, hogy a még működőképes gépek terheltsége alapján hová célszerű átrendezni azokat a processzeket, amelyek a meghibásodott gépen futottak. Ezután az így összeállított átrendezési listát elküldi a Migrációs modulnak, amely lényegében ugyanúgy működik, mint az automatikus terhelés kiegyenlítés esetén azzal a különbséggel, hogy nem az aktuális mérési periódus végén készített ellenőrző-pontot használja fel az átrendezéshez, hanem az eggyel korábbi mérési periódus végén készült ellenőrző-pontot. Ennek nyilvánvaló oka, hogy az utolsó ellenőrző-pont nem tartalmazza azokat a processzeket, amik a meghibásodott gépen futottak. Ebből az is következik, hogy egy ellenőrző-pontot csak az utána következő mérési periódus után lehet törölni.

 

A fenti megoldás biztosítja, hogy a dedikált klaszter egy (vagy akár több) gépének meghibásodása esetén nem kell az egész programot újrakezdeni, mindössze az utolsó mérési periódusbeli futást kell megismételni és a program futhat tovább a csökkentett méretű klaszteren.

 

A fenti automatikus terhelés kiegyenlítés és automatikus hibatűrés tulajdonságokkal a "Klaszter programozási technológia és alkalmazása a meteorológiában" c. IKTA-3 projekt keretében terjesztettük ki a P-GRADE rendszert.

 

2.3 Monitorozás és vizualizáció

 

A P-GRADE rendszer lehetővé teszi egy hosszan, akár több napon keresztül futó program monitorozását és vizualizációját is. Itt alapvetően két lehetőség közül lehet választani:

 

  1. Vizualizáció a felhasználó kérésére
  2. Periodikus vizualizáció

 

Az első esetben a PROVE processz-idő ablak "Collect" menűgombjával lehet a vizualizációt indítani. Hatására a GRM fő monitora összegyűjti a lokális monitoroktól az összes eddigi trace információt, majd az így összeállított trace állományt átadja a PROVE vizualizációs modulnak. Ez feldolgozza a begyűjtött trace információt és a 3.a ábrán látható processz-idő ablakban kirajzolja a processzek állapotátmeneteit és kommunikációit. Az ábrán a vízszintes tengely a végrehajtási időt reprezentálja, a függőleges tengely pedig a processzeket. Minden processzhez tartozik egy vízszintes vonal, melyben a különböző színek különböző állapotokat reprezentálnak (fekete = számítások, zöld = üzenetre várakozás, szürke = üzenet elküldésre várakozás). Két processz-vonalat összekötő nyíl reprezentálja a két processz közötti kommunikációt.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


                               a. PROVE processz-idő ablaka                                         b. PROVE Observ Dialog ablaka

 

3. ábra PROVE ablakok

 

A processz-idő ablak rendkívül hasznos egy párhuzamos program viselkedésének megértésében és ezért nagy szerepet játszik mind a párhuzamos programok fejlesztésében, mind futásuk ellenőrzésében. Egy jól belőtt párhuzamos programot teljesen mértékben magára lehet hagyni, de néhány óránként hasznos (és megnyugtató) lehet látni, hogy a program valóban úgy viselkedik, ahogy ezt elvárjuk tőle. Erre ad lehetőséget a PROVE "Collect" funkciója és a periodikus vizualizáció is, amit a 3.b ábrán látható Observ Dialog ablakkal lehet indítani. Itt lehet definiálni a trace információ begyűjtésének és vizulizációjának periódus idejét. Emellett a memória-felhasználás ésszerű mértéken tartása érdekében magadható, hogy mekkora az az időtartomány, amit vizualizálni akarunk. A PROVE modul csak azokat az adatokat tartja meg a memóriában és vizualizálja, amelyek a megadott időtartományba esnek. Így például a 3.b ábra beállítása azt jelenti, hogy 10 másodpercenként gyűjt adatot a GRM és vizualizál a PROVE, úgy hogy mindig az utolsó 1 perc eseményeit mutatja a processz-idő ablakban.

 

3. Végrehajtás szuperszámítógépen, vagy nem-dedikált klaszteren

 

Sok esetben a végrehajtásra nem dedikált klasztert használnak, hanem olyan szuperszámítógépet, vagy klasztert, amit több felhasználó között osztanak meg. Erre példa a NIIFI által működtetett Sun szuperszámítógép, amely az ország bármely kutatója számára nyújt szolgáltatást. Az ilyen sok-felhasználós rendszereken általában egy lokális job-kezelő rendszert alkalmaznak. A felhasználók jobként helyezik el programjukat a lokális job-kezelő várakozási sorában és a job-kezelő feladata, hogy a várakozó jobok és a rendelkezésre álló processzorok (gépek) összerendelését különböző, szabályozható stratégiák alapján elvégezze.

 

Tipikus lokális job-kezelő rendszerek a Sun Grid Engine (SGE), a Condor, a PBS és a LSF. Az SGE és a Condor nem csak egy szuperszámítógépen, vagy klaszteren belül, hanem több ilyen erőforrás között is képes elosztani a jobokat. Ezek tehát lehetőséget adnak arra is, hogy egy Gridhez hasonló rendszerben gondoskodjanak a job-kezelésről. Erre példa a magyar Klaszter Grid [5], ahol a Condort használjuk jobok elosztására a Gridet alkotó összes klaszter között.

 

Annak érdekében, hogy a P-GRADE-ben kifejlesztett programokat kényelmesen lehessen jobként futtatni szuperszámítógépeken, klaszterekben vagy a Gridben, kifejlesztettük a P-GRADE job-üzemmódját. Ez jelenleg a Condor [6] job-kezelőhöz van kötve, de se elvi, se gyakorlati akadálya nincs annak, hogy az SGE, vagy más job-kezelőkhöz is hozzákössük. A P-GRADE job-üzemmódjában alkalmazható funkciókat mutatja a 4. ábra. A szerkesztés, fordítás, monitorozás és vizualizálás funkciók a felhasználó szempontjából teljesen megegyeznek az interaktív módban és a job-módban. A leképezés funkció azonban itt kissé mást takar, mint az interaktív üzemmódban, ahol egy processzt konkrét géphez kell hozzárendelni.

4. ábra P-GRADE job-mód funkciók

 

Job-módban a Condorhoz hasonlóan erőforrás osztályokat lehet definiálni és a leképezés során azt kell megadni, hogy az egyes processzek mely osztályokon legyenek végrehajthatók. Az erőforrás osztályok definiálása érdekében kiterjesztettük az interaktív módban használt leképezés (mapping) ablakot, amint azt a 5. ábra legalsó ablaka mutatja. Itt három erőforrásosztályt definiáltunk. Mindegyik egy klaszter (SZTAKI: sztaki.hpcc.hu, Wisconsin Egyetem: cs.wisc.edu és Westminster Egyetem: cluster.cpc.wmin.ac.uk klasztere) és mindegyikből minimum 1, maximum 5 gépet kérünk a program párhuzamos végrehajtásához. Ezek az erőforrásosztályok a 0, 1 és 2 osztályazonosítókkal vannak ellátva és ezekkel lehet rájuk hivatkozni a mapping ablak "List of host" részében, ill. a "Process List - Host" részében. Az ábra mutatja, hogy a LowerLeft, MiddleLeft és UpperLeft processzek a 0 azonosítójú osztályhoz vannak rendelve, azaz a SZTAKI klaszterén kell futniuk.

 

Az már a Condor feladata, hogy a program futtatásához gondoskodjon az előírt gépeknek a lefoglalásáról és a megfelelő processzeknek ezen gépekre történő kiosztásáról. Annak érdekében, hogy a P-GRADE programot Condor jobként lehessen futtatni az "Execute" menüt kibővítettük a Submit job, Remove job, Detach job, Attach job funkciókkal. Ezek mind új funkciók, amik egyrészt a jobok indítását, leállítását segítik, másrészt lehetővé teszik, hogy miközben egy job fut valahol, a P-GRADE grafikus környezet más program fejlesztésére, vagy jobként történő indítására is felhasználható legyen (Detach job). Ha később szükséges a job visszakötése a P-GRADE-hez, akkor ezt az "Attach job" paranccsal lehet megtenni. Ha a P-GRADE és a job össze van kötve, a job monitorozása és vizualizálása ugyanúgy végezhető, mint az interaktív üzemmódban.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


5. ábra P-GRADE kiterjesztése a Condor job-mód támogatására

 

A P-GRADE Condor alapú job-üzemmódja a magyar Klaszter Gridben is jól használható, ha a P-GRADE telepítve van a Klaszter Grid belépési gépén. Ez esetben a P-GRADE alól indított job a Klaszter Grid bármely klaszterén, sőt egyszerre több klaszterén párhuzamosan is futtatható. A P-GRADE Condor alapú job-üzemmódját a Condort fejlesztő csoporttal közösen fejlesztettük ki és működését demonstráltuk a berlini CCGrid'2002 konferencia Grid Demo workshopján. Ebben a demonstrációban az 5. ábrán megadott 3 klaszteren párhuzamosan futott az 5. ábrán látható program.

 

4. Végrehajtás a Gridben

 

Egy párhuzamos program végrehajtására a harmadik lehetőség a Gridben történő végrehajtás. Ilyenkor nem ismerjük előre azt a szuperszámítógépet, vagy klasztert, amit a végrehajtásra akarunk használni, csak annyit specifikálunk, hogy az erőforrásnak milyen paraméterekkel kell rendelkeznie (processzorok száma, memória mérete, operációs rendszer típusa és verziója, stb.). Az már a Grid job-kezelő feladata, hogy a Grid információs rendszer segítségével találjon számunkra megfelelő erőforrást és utána gondoskodjon a job (beleértve a végrehajtható kódot és a szükséges állományokat) elküldéséről a kiválasztott erőforrásra. Sajnos ilyen Grid job-kezelőt nem találtunk és ezért fejlesztettük ki a PERL-GRID Grid job-kezelőt, amely egy általános Grid job-kezelő legalapvetőbb feladatait képes megoldani:

 

  1. Grid erőforrás kiválasztása (jelenleg ez egy primitív algoritmuson alapszik)
  2. A job (a végrehajtható kód és a szükséges állományok) elszállítása a kiválasztott erőforrásra
  3. Biztonságos SSH alapú kommunikáció biztosítása a kliens gép és a kiválasztott erőforrás között
  4. A kiválasztott erőforráson a job átadása a helyi job-kezelőnek (ez jelenleg a Condor lehet)
  5. A program lefutása után az eredmény állományok visszaszállítása a kliens gépre és a Grid erőforráson a job és a hozzátartozó állományok kitörlése

 

A PERL-GRID használata olyankor fontos, ha a P-GRADE rendszert futtató kliens gép nem tagja egy Condor-klaszternek, vagy a P-GRADE alól indított jobot egy másik Condor-klaszteren kívánjuk futtatni, amely nem áll "flocking" kapcsolatban a kliens gépet tartalmazó Condor-klaszterrel. Egy ilyen Grid rendszert demonstráltunk a piliscsabai 5. EU DataGrid konferencián (6. ábra). Az alkalmazási program az OMSZ MEANDER ultra-rövidtávú előrejelző programcsomagja volt, amit a "Klaszter programozási technológia és alkalmazása a meteorológiában" c. IKTA-3 projekt keretében az OMSZ és SZTAKI munkatársai közösen párhuzamosítottak P-GRADE alatt [7] (7. ábra). A demo során a piliscsabai Szent István Egyetem területéről egy notebookon futó P-GRADE rendszer alól indítottuk a jobot PERL-GRID üzemmódban. A PERL-GRID gondoskodott a job átszállításáról a SZTAKI klaszterére. Ott az OMSZ meteorológiai adatbázis leolvasása után a PERL-GRID átadta a jobot a lokális Condor job-kezelőnek, amely gondoskodott a program párhuzamos végrehajtásáról. (40 processzor vett részt a futtatásban.) A párhuzamos végrehajtás során a GRM monitor gyűjtötte a trace információt és a 2.3 fejezetben leírt módon a felhasználó kérésére a PROVE on-line vizualizációt (8. ábra) biztosított a P-GRADE-et tartalmazó notebookon. A program lefutása után a PERL-GRID gondoskodott a netCDF eredmény állomány elküldéséről Piliscsabára, ahol egy másik notebookon történt meg a meteorológiai térkép kirajzolása az OMSZ HAWK programcsomagja segítségével.

6. ábra P-GRADE job-mód és PERL-GRID együttműködésének demonstrációja

 

5. Összefoglalás és továbbfejlesztések

 

A P-GRADE egy kényelmes programfejlesztő és futtató környezetet biztosít párhuzamos programok fejlesztésére és futtatására szuperszámítógépeken, klasztereken és a Gridben. A program futtatása mind interaktív, mind job-módban lehetséges. A programok monitorozása és a végrehajtás vizualizálása mindkét üzemmódban támogatott függetlenül attól, hogy a végrehajtó rendszer szuperszámítógép, klaszter vagy egy Grid.

 

Megoldottuk a P-GRADE-ben fejlesztett és futtatott párhuzamos programok ellenőrző-pont készítését és ennek alapján az ilyen programok hibatűrő módon képesek futni a szuperszámítógépeken, klasztereken és a Gridben. Az ellenőrző-pont készítése a magyar Klaszter Grid szakaszos működési körülményei között is megengedi tetszőlegesen hosszan futó programok végrehajtását. Ha egy program nem fejeződik be az éjszakai Grid üzemmód alatt, akkor a nappali labor-módra történő átkapcsolás előtt a párhuzamos program ellenőrző-pontját a rendszer automatikusan elkészíti és a következő éjszakai Grid üzemmódba kapcsoláskor az elmentett ellenőrző-ponttól a párhuzamos program folytatható.

 

A P-GRADE fent leírt job-módja és Condorhoz ill. PERL-GRID-hez kötése a "Magyar Szuperszámítógép Grid" c. IKTA-4 projekt keretében történt. Ugyancsak e projekt keretében dolgozunk egy olyan jobflow (workflow) réteg kidolgozásán, amely lehetővé teszi a P-GRADE rendszer kiterjesztését a Gridben párhuzamosan működő és egymással együttműködő job-rendszerek definiálására és azok Gridben történő futtatására.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


7. ábra A MEANDER program párhuzamos verziója

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


8. ábra A MEANDER program végrehajtásának processz-idő diagramja

A P-GRADE a teljes magyar akadémiai közösség számára elérhető az NIIFI által üzemeltetett Sun E10000 szuperszámítógépen. A P-GRADE telepítve van az OMSZ SGI Origin 2000 szuperszámítógépén, ahol a korábban említett MEANDER párhuzamosítása történt a P-GRADE segítségével. E mellett intenzíven használják az oktatásban és kutatásban a varsói Lengyel-Japán Műszaki Főiskola Hitachi SR2201 szuperszámítógépén. Jelenleg folyik a P-GRADE installálása a Readingi Egyetem IBM SP2 szuperszámítógépére, ahol első sorban nagy numerikus feladatok megoldására kívánják használni.

 

A P-GRADE elsősorban Linux klaszterekre van telepítve (SZTAKI, Miskolci Egyetem, ELTE, Westminster Egyetem, Readingi Egyetem, stb.), de léteznek munkaállomás klaszter installálások is (SZTAKI, Bécsi Egyetem, Athéni Egyetem, stb.). A klaszteren futó P-GRADE alkalmazások között kell megemlíteni a Westminster Egyetemen kifejlesztett városi forgalom szimulátort és a Readingi Egyetemen fejlesztés alatt álló monte-carlo szimulációs alkalmazásokat.

 

A P-GRADE Grid adaptációja most van folyamatban.

Jelenleg dolgozunk azon, hogy a Magyar Klaszter Gridben és a Magyar Szuperszámítógép Gridben is használható legyen [8]. Ez utóbbiban a BME NTI-ben kifejlesztett  NAIMAN nevű programcsomag párhuzamosítását végezzük P-GRADE-ben. Ennek célja a szcintillátor-detektorok gamma-forrásokra adott válaszát modellezni. A "Kémiai Grid kialakítása és alkalmazása a légszennyezés rövid és hosszú távú előrejelzésében" c. IKTA-5 projektben az elemi reakciók kinetikájának és dinamikájának modellezésére, reakció-diffúzió rendszerek modellezésére, kémiai hullámok gerjeszthető közegben történő terjedésének modellezésére és Magyarország levegőszennyezettségének számítására használják a P-GRADE-et. Az EU D23-as COST alprogramhoz tartozó SIMBEX projekt célja egy európai kémikus Grid rendszer létrehozása. A projektnek 5 kémikus és 5 informatikus partner tagja van Európa hat országából. A SIMBEX konzorcium elfogadta, hogy a kémiai alkalmazások párhuzamosításának hivatalos eszköze a P-GRADE legyen. A "JGrid: Jini alapú Grid számítási rendszer és integrált grafikus alkalmazás fejlesztő környezet" IKTA-5 projekt célja többek között, hogy a P-GRADE az eddigi C, C++ és Fortran támogatás mellett képes legyen Java programok fejlesztését is támogatni.

 

A P-GRADE 8.2 verzió (amely az interaktív üzemmódot támogatja) bináris kódja, kézikönyve és a mintaprogramok gyűjteménye ingyenesen letölthető a www.lpds.sztaki.hu web oldalról. Igény esetén bárkinek szívesen rendezünk P-GRADE tanfolyamokat. Hamarosan tervezzük a 8.4 verzió kiadását, amely már magában fogja tartalmazni a job-mód támogatását is.

 

Hivatkozások

 

[1] Kacsuk P.: Visual Parallel Programming on SGI Machines, Meghívott előadás, SGI Users' Conference kiadványa, Krakow, Poland, pp. 37-56, 2000

 

[2] P-GRADE User's Manual: www.lpds.sztaki.hu

 

[3] Kovács J. és Kacsuk P.: Server Based Migration of Parallel Applications, DAPSYS'2002 workshop kiadványa, Linz, pp. 30-37, 2002

 

[4] Tóth M. L., Podhorszki N. és Kacsuk P.: Load Balancing for P‑GRADE Parallel Applications, DAPSYS'2002 workshop kiadványa, Linz, pp. 12-20, 2002

 

[5] Stefán P. A magyar ClusterGRID projekt, Networkshop'2003, Pécs

 

[6] Condor User's Manual: http://www.cs.wisc.edu/condor/manual

 

[7] Lovas R., Kacsuk P. Horváth Á. és Horányi A.: Application of P‑GRADE Development Environment in Meteorology, DAPSYS'2002 workshop kiadványa, Linz, pp. 109-116, 2002

 

[8] Kacsuk P.: A magyar Grid projektek áttekintése, Networkshop'2003, Pécs

 


[1] A cikkben leírt kutatásokat a következő projektek támogatták: OTKA T032226, OMFB-02307/2000, IKTA-00075/2001 és EU DataGrid IST-2000-25182