1 UVOD
Simulacije dinamično trianguliranih površin so metode
Monte-Carlo. Na površino, ki jo želimo simulirati, na-
pnemo trikotniško mrežo, ki lahko v okviru izbrane
verjetnostne porazdelitve in robnih pogojev spreminja
Prejet 8. junij, 2019
Odobren 11. oktober, 2019
tako obliko kot tudi povezanost vozlišč [1], [2]. Spre-
membo oblike površine dosežemo predvsem s premi-
kanjem položaja vozlišč trikotniške mreže, spreminjanje
povezav med vozlišči pa omogoči tudi lateralno mobil-
nost vozlišč v mreži. Tako simulirana površina se obnaša
kot dvodimenzionalna tekočina, kar je pomembna la-
stnost membran, katerih osnova je dvojna plast lipidnih
molekul [3]. Zato simulacije dinamično trianguliranih
površin pogosto uporabljamo pri modeliranju lipidnih in
bioloških membranskih sistemov [2], [4 - 8].
Pomemben primer membran, tankih ločnic med
dvema območjema, so membrane bioloških celic. Celice
različnih velikosti, oblik in funkcij so osnovni sestavni
deli bioloških sistemov. Kljub raznolikosti celic, ki jih
najdemo v bioloških sistemih, so osnovni gradniki in
njihova kemijska sestava večine celic enaki [3], [4],
[5]. Lastnosti bioloških membran, ki obdajajo celice ali
njene organele, se precej razlikujejo od lastnosti ma-
kroskopskih objektov, ki smo jih vajeni iz vsakdanjega
življenja. Najštevilnejši gradniki celičnih membran so
lipidne molekule, med katerimi prevladujejo fosfolipidi,
ki skupaj z vgrajenimi proteini sestavljajo skoraj vso
maso membrane [6]. Fosfolipidne molekule so amfifilne,
kar pomeni, da so sestavljene iz hidrofobnega in hidro-
filnega dela. V vodnem mediju se tako samoorganizirajo
v fosfolipidno dvojno plast, ki lahko tvori mehurčke
oziroma vezikle (angl. vesicle). Takšna dvojna plast
je lahko tako upogljiva, da je izpostavljena termičnim
fluktuacijam, ki lahko pomembno vplivajo na njene
fizikalne lastnosti in biološke funkcije.
284 PENIČ, FOŠNARIČ
Triangulirane površine kot model lipidnih in bioloških
membranski sistemov so model s skaliranjem (angl.
coarse-grained model). V trikotniški mreži lahko en
trikotnik ali eno vozlišče in njegova neposredna okolica
modelira del membrane, ki jo zapolnjuje več mole-
kul membrane. Interakcijo teh delov mreže z okolico
opišemo s primernimi fizikalnimi modeli. Modeli s
skaliranjem so nepogrešljiv del modeliranja bioloških
sistemov [4], [3], omogočajo kvalitativen vpogled na
dogajanje v membranah in pripomorejo k razumevanju
biofizikalnih lastnosti bioloških struktur [7].
Spisati programsko kodo za simulacije dinamično
trianguliranih površin je sorazmerno zahteven projekt.
Zato smo simulator trisurf, ki je razvit prav za
simulacije dinamično trianguliranih površin, izdali pod
odprtokodno programsko licenco [8]. Fizikalni model,
na katerem temelji simulator, je podrobneje opisan v
[9], algoritem pa v [10]. Surovi rezultati simulatorja
so oblika membrane, torej matematični opis trikotniške
mreže – pozicije posameznih točk mreže in vezi med
njimi, ter druge fizikalne lastnosti posameznih delov
membrane, ki jih pripišemo mreži.
Časovno dolgotrajne simulacije pospešimo z vzpore-
dnim računanjem. Poskus vzporednega računanja, kjer
več procesov izvaja premike Monte Carlo na enem
samem sistemu (npr. veziklu), smo v zgodnji fazi ra-
zvoja nadomestili z učinkovitejšo in preprostejšo obliko
paralelizacije. Iz izbranega začetnega stanja naredimo
vzporeden zagon simulacij. Vsaka simulacija lahko
obravnava sistem z drugačnim naborom parametrov
ali pa z enakim. Pri slednjem praviloma zavržemo
toliko začetnih korakov, da stanja med seboj niso
več statistično korelirana. Tako vsak zagon simulatorja
preračunava ločen sistem in odpadejo težave vzpore-
dnega računanja, kjer se lahko procesi med sabo motijo.
Simulacije se lahko izvajajo na več računalnikih, ki niso
nujno ves čas povezani med seboj. V praksi smo se po-
gosto srečevali s potrebo prečesavanja faznega prostora,
torej širokega nabora parametrov [11]. Takrat smo delo
praviloma razdeljevali tako, da je vsak računalnik (ali
procesorsko jedro istega računalnika) izvajal simulacijo
z ločenim naborom parametrov.
V članku predstavimo sistem upravljanja vzporednega
računanja in dela s podatki. Sistem uporablja simulator
trisurf, vendar je prilagodljiv in odprtokoden, zato
ga je mogoče uporabiti tudi pri drugih projektih. Pri
načrtovanju hranjenja podatkov je sistem zastavljen tako,
da je omogočen hiter dostop do množice rezultatov
simulacij. Celovitost sistema smo zagotovili tudi z upo-
rabniškim vmesnikom, s katerim je mogoča tako analiza
rezultatov kot tudi njihova dokumentacija in priprava za
znanstveno objavo.
2 RAČUNANJE V GRUČAH IN
PORAZDELJENO RAČUNANJE
Simulacije Monte Carlo so računsko zahtevne (potrebu-
jejo veliko procesorske računske moči), niso pa zahtevne
glede pomnilnika ali prostora za shranjevanje vmesnih
rezultatov. Zaradi potrebe po računski moči smo za-
snovali sistem za vzporedno računanje, pri čemer smo
raziskali dve tehniki, ki sta primerni za naš problem.
Izognili smo se vzporednemu računanju na istem sis-
temu (npr. isti trikotniški mreži), saj ta pristop zahteva
komunikacijo med posameznimi procesi in je skalabilen
samo do neke mere. Rezultate posamezne simulacije
(primera za izbran nabor fizikalnih parametrov), bi tako
sicer pridelali hitreje, vendar bi del procesorskega časa
porabili za upravljanje med procesi in za zagotavljanje,
da se procesi med samim delom ne motijo. Izbrali
smo drug pristop. Ker nas običajno zanima večji del
faznega prostora, torej širok nabor parametrov, kjer
potrebujemo za vsako kombinacijo parametrov svojo
simulacijo, smo paralelizirali zagon več neodvisnih si-
mulacij. Tako so posamezne simulacije samostojne in
ne potrebujejo medsebojne komunikacije. Pri manjšem
zahtevanem številu vzporednih simulacij, kjer sodeluje
le nekaj računalnikov, je mogoč ročen zagon posameznih
simulacijskih procesov, kar pa je pri večjem številu
vzporednih simulacij zelo težko izvajati in spremljati.
Zato smo razvili avtomatiziran sistem za zagon simula-
torja.
Za hitro računanje se je zgodaj v razvoju računalnika
začel razvoj metod za vzporedno računanje na več
računalnikih hkrati. Prve tehnike so bile računanje v
gručah (angl. cluster) in mrežnega procesiranja (angl.
grid computing) [12], čedalje bolj pa postaja popularno
porazdeljeno procesiranje, kjer sta popularna pristopa
računanje v oblaku (angl. cloud computing) in oportu-
nistično računalništvo (angl. volunteer computing) [13].
Za upravljanje računskih procesov programiranja v
gručah sta razširjena odprtokodna projekta SLURM in
PBS, namenjena podpori lokalnim gručam računalnikov
in mrežnemu procesiranju. Projekt SLURM se je začel
razvijati leta 2002 kot sistem za upravljanje z računskimi
zmogljivosti računalnikov v gručah z nameščenim ope-
racijskim sistemom Linux, pozneje pa so mu dodali
robusten sistem za razdeljevanje dela (angl. scheduling).
Danes je SLURM odprtokodna platforma za razdelje-
vanje računskega dela med računalnike v gručah in
njihov nadzor. Razvoj sistema PBS se je začel že leta
1991 kot odprtokodna platforma za razdeljevanje dela
v gručah in je del projekta OpenHPC. Omeniti velja še
projekt HTCondor, ki je odprtokodni razdeljevalnik dela
v mrežnem računalništvu in ga uporablja npr. Amazon
EC2 [12].
Sisteme masovnega oportunističnega distribuiranega
računanja je populariziral projekt Seti@Home [14]. Pro-
stovoljci pri projektu prispevajo računske zmogljivosti
svojih računalnikov za analizo signalov, prejetih iz ra-
ORODJE ZA PORAZDELJENO RAČUNANJE IN ANALIZO MONTE CARLO SIMULACIJ FOSFOLIPIDNIH VEZIKLOV 285
dijskih teleskopov v upanju, da bodo naleteli na signale,
ki jih v vesolje pošiljajo inteligentna bitja zunaj našega
osončja. Seti@Home sicer ni bil prvi tak projekt, vendar
je pokazal, da je oportunistično računanje izvedljivo,
in kmalu se je razvila množica podobnih znanstvenih
projektov. Seti@Home je se sčasoma preselil na BOINC
(kratica za Berkeley Open Infrastructure for Network
Computing), ki omogoča platformo za distribucijo oro-
dij za oportunistično računanje [15]. BOINC so začeli
razvijati leta 2002 in je hitro postal vodilna platforma
za oportunistično računanje. Na platformi BOINC se tre-
nutno izvaja več kot 30 znanstvenih projektov svetovnih
razsežnosti [16].
Zahtevane naloge
Generator delovnih nalog
SQL baza podatkov
Upravljalnik dela API Delavci
Rezultati v datotekah
Rezultati
Slika 1: Poenostavljena zgradba sistema BOINC, prirejena po
[17]
Razlika med pristopoma za računanje v gručah in
oportunističnega procesiranja je velika. V gručah nasto-
pajo računalniki, ki so med seboj (praviloma) enaki in
povezani s hitrim računalniškim omrežjem. Računalniki
delujejo konstantno in zanesljivo, zato imamo med
računanjem na voljo konstantno računsko moč. Re-
zultati, ki jih zberemo iz posameznih računalnikov v
gruči, so varni – v njihovo pravilnost lahko zaupamo,
saj je cela gruča pod kontrolo administratorja ali iz-
vajalca računskega projekta [12]. Oportunistično pro-
cesiranje se izvaja na računalnikih prostovoljcev, ki so
povezani v splet in so pripravljeni darovati računske
zmogljivosti svojih naprav. Te so zelo raznolike, imajo
nameščene različne operacijske sisteme, strojno opremo
. . . Računalnikov, ki izvajajo računsko delo (delavcev),
ne moremo kontrolirati in ti se lahko kadarkoli izključijo
ali izgubijo povezavo s strežnikom, ki deluje kot razde-
ljevalec dela. Ravno tako ne moremo zaupati rezultatom
oddaljenih računalnikov v lasti prostovoljcev, saj lahko
ti delujejo nepravilno ali so zlonamerno prilagojeni tako,
da vračajo slabe rezultate [12], [18].
Pri postavitvi našega sistema za izvajanje simulacij
smo se odločili za oportunistično procesiranje, saj ni-
smo imeli dostopa do homogenega sistema v gruči.
Zaradi specifik simulatorja trisurf in relativno zah-
tevne postavitve sistema BOINC je bilo pri sistemu za
upravljanje simulacij trisurf hitreje in pregledneje
razviti lasten sistem za razdeljevanje dela in računanje na
oddaljenih računalnikih prostovoljcev. Zgledovali smo
se po poenostavljeni zgradbi sistema BOINC (brez
določenih delov, ki spremlja računsko delo in nagra-
juje prostovoljce) in po podobnem sistemu projekta
Folding@Home [19]. Glavni deli sistema BOINC so
predstavljeni na sliki 1. Raziskovalec sestavi naloge
in sistem BOINC ima svoj lasten generator preprostih
nalog, ki jih razdeli delavcem po protokolu HTTP in
prirejenim API vmesnikom. Delavci dostopajo do dela,
shranjenega v bazi, prek internetnega API vmesnika
(odebeljena puščica na sliki), ki je neposredno pove-
zan z razdeljevalno enoto upravljalnika dela. Računske
rezultate delavec vrne na strežnik in upravljalnik dela,
ki shrani datoteko z rezultati na disk. Tako zbrani
neobdelani (surovi) rezultati so na voljo raziskovalcu za
analizo, ki jo izvede zunaj sistema BOINC.
API za vnos simulacij
SQL baza podatkov
Upravljalnik dela API Delavci
Rezultati v datotekah
Jupyter delovni zvezek za analizo
Slika 2: Zgradba sistema trisurf
Načelna poenostavljena zgradba projekta trisurf,
ki ne vsebuje le simulatorja, ampak tudi okolje za
vzporedno računanje in analizo podatkov, prikazuje slika
2. Razliki v shemah na slikah 1 in 2 sta le pri ge-
neriranju nalog in pri analizi podatkov. Pri generira-
nju dela je treba pri sistemu trisurf delo definirati
izven sistema. Delovne naloge (posamezne simulacije)
se v bazo vnesejo prek spletnega vmesnika, ki deluje
po protokolu HTTP in REST API (angl. Represen-
tational Sate Transfer Application protocol Interface).
Analizo surovih podatkov, zbranih v datotekah XML,
smo vključili kar v sistem trisurf v obliki delov-
nega zvezka Jupyter. Na glavnem strežniku projekta
286 PENIČ, FOŠNARIČ
trisurf je tako nameščen program, spletni vmesnik
namenjen raziskovalcem, hkrati pa shranjuje podatke in
metapodatke posameznih raziskav, simulacij in surovih
rezultatov, izračunanih s simulatorjem trisurf. Hkrati
je tudi razdeljevalec računskega dela in zbiralnik re-
zultatov. Napisan je v programskem jeziku Python, pri
čemer smo uporabili okolje Django za razvoj spletne
aplikacije in upravljanje podatkovne baze. Komunikacija
z računalniki, ki izvajajo računsko delo (delavci), poteka
prek strani REST API in protokola HTTP.
Za računalnike, ki opravljajo simulacije, je trenutno
podprt le operacijski sistem Linux. Na nje je potreba
namestiti simulator trisurf in preprost Pythonov
vmesnik, ki komunicira s strežnikom. Delavec se najprej
prijavi in strežniku sporoči nameščeno različico simula-
torja trisurf. Ta mu na podlagi sporočene različice
in seznama prostih del dodeli simulacijo ter mu pošlje
podatke za izvajanje (zadnji rezultat ali konfiguracijsko
datoteko, če v bazi ni še nobenega rezultata). Vmesnik
na delavcu zažene simulator s prejetimi podatki in
spremlja napredek simulacij.
Ker je delovanje delavcev nezanesljivo (prekinitve
v računanju, počasnost, nenapovedljivi izklopi delav-
cev), mora vmesnik na delavcu v določenih intervalih
sporočati strežniku stanje delovanja in potrjevati delo
na simulaciji. Ko simulator vrne rezultat (novo mi-
krostanje), ga vmesnik na delavcu pošlje na strežnik.
Ta zabeleži transakcijo in shrani rezultat v ustrezno
mapo. V primeru napake v komunikaciji ali neodzivnosti
delavca strežnik simulacijo postavi v seznam prostih
simulacij, ki čakajo na ponovno razdeljevanje delavcem.
Zaradi izbrane tehnologije nima strežnik nad delavci
nikakršne kontrole, zato je pomembno, da delavec v
vnaprej določenem času posreduje podatke o delovanju.
Pobudnik komunikacije je vedno delavec. Zaradi upo-
rabe protokola HTTP je delovanje sistema mogoče tudi,
če so delavci zavarovani s požarnimi zidovi ali drugimi
varnostnimi tehnologijami.
3 HRANJENJE PODATKOV
Surovi podatki, ki jih dobimo iz simulacij, so mikro-
stanja sistema (npr. vezikla) v obliki XML (primerna
tudi za pregledovanike, ki podpirajo format VTK), z
metapodatki o parametrih, s katerimi je bila izvedena
simulacija z različico simulatorja trisurf, s katerim je
bilo stanje pridobljeno, ter datumom in časom nastanka.
Sproti se izračuna še nekaj metrik vezikla, ki jih želimo
spremljati med samim izvajanjem simulacij.
Za organizacijo surovih podatkov uporabljamo odpr-
tokodno podatkovno bazo PostgreSQL. Vsako uspešno
izračunano stanje, ki ga klient prenese nazaj k razde-
ljevalcu, razdeljevalec zabeleži v tabeli izmenjave po-
datkov, rezultat shrani na disk v obliki datoteke XML,
referenco na to datoteko pa v podatkovno bazo. Razisko-
valec ima tako možnost iskanja in selekcije specifičnih
datotek z uporabo običajnih orodij SQL ali z njihovimi
Djangovimi razširitvami. Tabele v bazi so zgrajene hie-
rarhično. Najvišja stopnja je projekt, vsak projekt ima
lahko več raziskav in vsaka raziskava več simulacij.
Surovi podatki pripadajo posamezni simulaciji. Vsaka
stopnja v hierarhiji je opremljena z ustreznimi metapo-
datki za lažje iskanje in selekcijo ustreznih podatkov za
analizo.
Količina pridobljenih podatkov v nekaj letih raziskav
preseže velikost sodobnih trdih diskov. Trenutno ve-
liko količino podatkov obvladujemo z diskovnimi polji
RAID, hkrati pa raziskujemo možnosti za distribuirano
hranjenje podatkov in hranjenje podatkov v oblaku z
odprtokodnima projektoma GlusterFS in Ceph [20].
4 OBDELAVA PODATKOV
V svetu množice podatkov je komunikacija z
računalnikom le del izziva. Pomemben del je tudi
komunikacija s sodelavci, kolegi iz stroke in širšo
javnostjo. Zato je pregleden sistem podatkov in
algoritmov ključnega pomena za efektivno delo s
podatki.
Za obdelavo podatkov smo izbrali odprtokoden pro-
gramski jezik Python, ki je visokonivojski, torej soraz-
merno proprost za uporabo ter širokonamemben in s
tem tudi dobro podprt. Python skupaj z odprtokodnimi
knjižnicami, kot so numpy, scipy, matplotlib
in druge, postavlja de facto standard za znanstveno
računanje [21]. Python se tako postavlja ob bok pro-
gramskim paketom, kot sta Matlab in Mathematica, in
jih ponekod celo presega [22]. Python po svoji zasnovi
sledi principom DRY (angl. Don’t Repeat Yourself) in
tako veščega uporabnika spodbuja k ponovni uporabi že
narejenih algoritmov.
Zaradi centralizirane hrambe velike količine podat-
kov je obdelava na lokalnih računalnikih nepraktična,
zato smo se odločili za obdelavo podatkov direktno
na strežniku brez potrebe po kopiranju podatkov s
strežnika na lokalni računalnik prek spleta. Raziskovalec
ima dostop do uporabniškega vmesnika preko spletnega
brskalnika in programskega paketa Jupyter. Tako vse
razvojno in raziskovalno delo poteka na centralnem
strežniku z neposrednim dostopom do podatkov.
Jupyter je odprtokodni projekt, ki se je razvil iz
interaktivnega vmesnika za Python (podobnega, kot je
npr. Matlab). Sprva je bil uporabniški vmesnik dostopen
prek terminalskega okna na računalniku v izbranem
operacijskem sistemu, Jupyter pa je prestavil uporabniški
vmesnik v spletni brskalnik, dodal tehnologijo server-
client in tako omogočil delo v oblaku. Sam vmesnik
spominja na obliko delovnega zvezka (angl. notebook),
kakršno poznamo iz programskega paketa Mathematica.
Osnovni gradnik delovnega zvezka je celica, ki lahko
vsebuje programsko kodo ali besedilo v jeziku markup in
podpira TEXov sistem pisanja enačb. Projekt Jupyter po-
leg delovnega zvezka omogoča tudi vgradnjo elementov
spletnih strani, zato lahko z njim naredimo tudi prototipe
ORODJE ZA PORAZDELJENO RAČUNANJE IN ANALIZO MONTE CARLO SIMULACIJ FOSFOLIPIDNIH VEZIKLOV 287
uporabniške aplikacije. Tipičen primer so ponavljajoče
se analize podatkov.
Raziskovalec, ki analizira podatke, si v delovnem
zvezku Jupyter tako sproti, medtem ko razvija algoritem
za obdelavo podatkov, ustvarja ekvivalent laboratorij-
skega dnevnika ali zapiskov, ki jih pozneje uporabi
kot osnovo za pisanje znanstvenega članka. Dostop do
spletnega vmesnika je omogočen od koderkoli, zato je
mogoče delo na daljavo in s kakršnimkoli terminalom,
od osebnega računalnika do mobilnega telefona. Format
Jupytrovega delovnega zvezka je odprti standard, zato ga
podpira že veliko pregledovalnikov in spletnih storitev.
Delovni zvezek pa lahko vedno izvozimo tudi v formatu
pdf ali v čisti izvorni kodi Python.
Projekt Jupyter je hitro razvijajoč se sistem, ki ima
ogromno privržencev med raziskovalci, predvsem na
fizikalnem področju. Pred nekaj leti so začeli razvijati
naprednejši sistem delovnih zvezkov JupyterLab, ki bo
omogočal tudi terminalski dostop do strežnika in do
lupine Python.
Pri načrtovanju učinkovitega sistema za obdelavo re-
zultatov s projektom Jupyter smo se oprli na osem točk
dobre prakse računalniške obdelave podatkov, povzetih
po članku [23].
1) Programi naj bodo berljivi in pisani za ljudi,
ne za stroje
Prednost pred samo hitrostjo izvajanja je berlji-
vost kode, saj je čas raziskovalca vreden več
kot računski čas računalnika. Raziskovalcu je
omogočen preprost dostop do podatkov iz celo-
tne baze izračunanih in shranjenih mikrostranj,
kot tudi dostop do podatkov o njih. Hkrati je
omogočen dostop do funkcij samega simulatorja,
napisanega v programskem jeziku C preko pove-
zovalnih funkcij Python. Raziskovalec lahko tako
poustvari sliko vezikla med simulacijo in pridobi
dodatne podatke, ki niso del že vnaprej opravljenih
analiz.
Uporabnika/raziskovalca spodbujamo k pisanju
berljive programske kode za obdelavo podatkov,
saj je lahko ta ponovno uporabljena pri drugih
projektih, hkrati pa služi kot dokumentacija raz-
iskovalnega dela.
2) Računalnik naj opravlja težaška opravila
Pri obdelavi podatkov, še zlasti pri statistični ob-
delavi, kjer se ukvarjamo s kopico podatkov, je
smiselno, da ponavljajoča se opravila opravi kar
računalnik sam. Raziskovalcu so na voljo pogo-
ste rutinske obdelave podatkov, sam pa si lahko
sestavi dodatne funkcije, ki presegajo osnovno
zasnovo sistema. Sem spadajo tudi razni sistemi
za gradnjo začasnih podatkovnih baz in dolgotraj-
nejših analiz podatkov.
3) Spremembe v algoritmih naj bodo inkremen-
talne
Med delom spodbujamo raziskovalca, da razvija
svoj algoritem počasi in sproti preverja pravilnost
rezultatov. Zelo priporočljiva je uporaba sistemov
za upravljanje različic (angl. versioning system),
v katerih se zrcali celotna evolucija razvoja algo-
ritmov obdelave podatkov.
4) Ne ponavljaj stvari, ki si jih že naredil (oz. so
jih naredili drugi)
Raziskovalec naj uporablja že napisane knjižnice.
Smiselno je tudi, da svoje algoritme v obliki
objektov ali funkcij združi v module, ki jih nato
uporablja iz več raziskovalnih projektov. Funkcije,
ki se pri obdelavi simulacijskih podatkov pogo-
steje uporabljajo, smo zapakirali v modul, ki ga
preprosto vključimo v delovni zvezek.
5) Pričakuj napake v podatkih in pri obdelavi
Vnos podatkov v algoritem je vedno lahko obre-
menjen z napako (naj bo to manjkajoč podatek
ali pa podatek napačnega tipa). Programiranje
raziskovalca naj bo defenzivno, kar pomeni, da
naj se vsi podatki preverjajo pri prenosu med po-
sameznimi segmenti analize. Priporočljiva je tudi
uporaba t. i. unit testov, ki zagotavljajo pravilno
delovanje posameznih enot/funkcij algoritma.
6) Optimiziraj algoritme šele, ko ti delujejo pra-
vilno
Izogibajmo se prehitre optimizacije programske
kode. Računsko zahtevne segmente optimiziramo
šele potem, ko je sestavljen celoten algoritem za
analizo, če je to potrebno. Optimalna je uporaba
nižjenivojskega programskega jezika (npr. C). V
Jupytru sam jezik C ni podprt, lahko pa del
kode sestavimo kot vgrajen program C in paket
cython.
7) Dokumentiraj namen algoritma, ne izvedbe
Ideja delovnih zvezkov je v združevanju program-
ske kode in dokumentacije. Programska koda je
poleg samega izvajanja računanja del dokumen-
tacije. Programsko kodo dopolnjujemo z besedi-
lom, ki opisuje namen posameznega dela kode ali
interpretacijo rezultatov. Samih tehničnih detajlov
algoritma ne opisujemo, če to ni nujno potrebno,
saj naj bi bilo samo delovanje kode razvidno iz
kode same. V okolju Jupyter lahko za dokumen-
tacijo uporabimo jezik z značkami za opis oblike
besedila (angl. markup language).
288 PENIČ, FOŠNARIČ
8) Sodeluj
Sodelovanje raziskovalcev pri raziskovalnem delu
je ključnega pomena. Pogosto uporabljamo pro-
gramiranje v parih, kjer dva raziskovalca skupaj
razvijata algoritem za obdelavo podatkov. Pred
objavo rezultatov je priporočljiv tudi neodvisen
pregled algoritmov tretje osebe, ki opozori na
morebitne nepravilnosti pri raziskovalnem delu, ki
jih je raziskovalec spregledal.
V duhu znanstvenega sodelovanja in deljenja
znanstvenih podatkov naj raziskovalec deli svoje
algoritme za obdelavo z drugimi tako, da omogoči
dostopnost svojih programov na javno dostopnih
servisih.
5 SKLEP
Avtomatiziran sistem razdeljevanja simulacij sistema
trisurf je narejen po zgledu podobnih razdeljeval-
nikov sistemov oportunističnega računanja. Ker so si-
mulacije računsko zahtevne, smo z uvedbo vzporednega
računanja pospešili izvajanje raziskav. V praksi se je po-
kazalo, da je veliko pomembnejše, kako so programi ber-
ljivi (raziskovalcu), kot pa njihova optimizacija. Sistem
je zasnovan tako, da je čim bolj približan uporabniku,
torej raziskovalcu, ki pripravlja parametre za simulacije
in obdeluje podatke. Pri zasnovi sistema trisurf smo
uporabili odprtokodne tehnologije, sam sistem pa smo
izdali pod odprtokodno licenco GPL različice 3 ali
poznejše. Izvorna koda sistema je v celoti na voljo v
repozitoriju GIT [24].
Zaradi podobnosti razdeljevalnika z razdeljevalnikom
platforme BOINC raziskujemo možnosti prilagoditve
simulatorja za uporabo s sistemi BOINC in SLURM, kot
je opisano v [25]. Kombinirana uporaba obeh sistemov
omogoča tako oportunistično računanje kot računanje v
gručah. Za shranjevanje velikih količin podatkov pre-
dlagamo uporabo porazdeljenega datotečnega sistema
GlusterFS.