Virkeligheten som simuleringspill

Sagt enkelt er SIMULA et verkt?y som ble laget for ? kunne "etterape" - simulere - komplekse situasjoner og forl?p i virkeligheten, med mange komponenter (objekter) og tilstander. N?r vi i dag sitter foran PC-en og skriver, klipper, redigerer, lagrer og holder styr p? en mengde objekter - tekstdokumenter, bilder, mapper og regneark - er det arven fra SIMULA vi benytter oss av. N?r arkitekten sitter foran skjermen og skyver rundt p? vegger, d?rer og vinduer, er det ogs? SIMULAs objektorienterte tiln?rming som ligger bak tegneprogrammet.

Professor Ole-Johan Dahl har v?rt Kristen Nygaards partner i SIMULA-prosjektet og har v?rt helt sentral i oppbyggingen av Institutt for informatikk. Foto: St?le Skogstad

Dette krever en grundigere forklaring. Men SIMULAS ene far, professor Kristen Nygaard , nekter ? gi den i stikkordsform. Vil du v?re med, s? heng p?! Reisen g?r mer enn 50 ?r tilbake i tiden og viser det tette samspillet det har v?rt mellom Forsvarets forskningsinstitutt (FFI), Norsk Regnesentral og etter hvert Institutt for informatikk.

Hvordan dimensjonere en atomreaktor?

?ret er 1948. Unge Nygaard er soldat som tjenestegj?r ved FFI. Krigens siste fase hadde avsl?rt kjernekraftens uhyrlige energipotensial. N? var sp?rsm?let: Hvordan kan denne kraften utnyttes p? en kontrollert m?te til sivilt bruk? Ogs? lille Norge hadde g?tt l?s p? utfordringene og var i ferd med ? bygge opp landets f?rste atomreaktor p? FFI p? Kjeller utenfor Oslo. P? det ytre var reaktoren s? n?r som ferdig designet, men det st?rste problemet var ul?st: For ? oppn? en riktig mengde atomspaltinger (fisjoner) som kunne s?rge for den riktige energiutviklingen, var diameteren p? atomstavene helt avgj?rende. En gal diameter ville enten ikke gi mange nok reaksjoner, eller omvendt, kunne f?re til ukontrollert kjedereaksjon.

- Amerikanske myndigheter var, da som i dag, meget redde for at atomkraften skulle komme p? vidvanke, s? dette med diameteren var et meget hemmelig tema. Det stod ikke i "oppskriften", vi ble n?dt til ? beregne den p? egen h?nd. Jan V. Garwick ved FFI - informatikkens far i Norge - startet med beregningene, og n? skulle jeg ta over arbeidet. Dette var f?r vi hadde elektroniske datamaskiner. Vi brukte papir og penn og elektromekaniske regnemaskiner og det vi kaller anvendt matematikk. Vi fant fram til de likningene som beskrev det fysiske fenomenet, og l?ste dem numerisk. Dette viste seg ? v?re en tungvint arbeidsm?te. Etter hvert var vi seks-sju mennesker som arbeidet full tid. Da kom vi over en amerikansk metode som ble kalt Monte Carlo-metoden, sier Nygaard.

Virkeligheten som tombola

Denne metoden beskrev hvordan man kunne simulere, etterape, den fysiske prosessen inne i reaktoren. Der delte enkelte urankjerner seg - de fisjonerte. Det medf?rte at en del n?ytroner ble kastet ut med stor hastighet og etter hvert kolliderte med atomene i n?rheten og spratt videre til nye kollisjoner. Dersom et n?ytron hadde blitt bremset ned til en passende hastighet (spesielt av atomkjernene i det tunge vannet i reaktoren) og s? traff en uran 235-atomkjerne, kunne n?ytronet f? denne kjernen til ? fisjonere. Dermed ble det utl?st ny energi og nye hastige n?ytroner. Det var viktig ? finne det riktige gjennomsnittet p? fisjonen. Et meget h?yt gjennomsnitt ville gi en katastrofe, i verste fall en atombombe.

Det den amerikanske rapporten viste, var at man p? papir kunne lage en beregningsprosess som kunne etterape atferden til n?ytronene. Man kunne simulere banene og kollisjonene til et stort antall n?ytroner og ta statistikk over hvordan de simulerte n?ytronene oppf?rte seg i samlet sum.

- Men n? var det slik at en kollisjon mellom et passende langsomt n?ytron og en passende uranatomkjerne ikke alltid ledet til en ny fisjon. La oss anta at bare 23 % av slike kollisjoner ledet til fisjon. Hvordan skulle denne tilfeldigheten, med 23 % sannsynlighet, etterapes? Det ble gjort med en "trekke lodd"- eller "tombola"-teknikk. Derfor navnet Monte Carlo-metoden.

- Teknikken kan illustreres slik: Anta at vi hadde en tombola fylt med 100 lapper, nummerert "00", "01", "02", opp til "99". Hver gang vi fulgte et n?ytron og det fikk en "passende" kollisjon, avgjorde vi om det ledet til en ny fisjon ved f?lgende regel: Vi snurret p? tombolaen og trakk en lapp. Dersom tallet var mindre enn "23", sa vi at det ble utl?st en ny fisjon, ellers ikke. Hva vil gjennomsnittet bli for et stort antall slike kollisjoner? 23 % - siden det er 23 lapper av 100 med tall mindre enn 23, sier Nygaard, og legger til at de klarte ? gjennomf?re beregningene med Monte Carlo-metoden atskillig raskere enn med den tradisjonelle numeriske metoden. Og siden det ikke berettes om atomkatastrofe eller atom-fiasko p? Kjeller i begynnelsen av 1950-?ra, kan man slutte at beregningene var korrekte.

- Men ikke alle trodde det skulle g? slik. Den fargerike professor Ivan T. Rosenqvist lovet p? forh?nd at "han var villig til ? sitte p? toppen av reaktoren i bare underbuksa" n?r vi fors?kte ? starte den opp. Han ombestemte seg dog, humrer Nygaard.

Milit?re taktikkstudier

Poenget er at Nygaard n? for alvor hadde f?tt ?ynene opp for at man ved hjelp av matematiske spill kunne simulere prosesser i virkeligheten. Etter hvert ekspanderte beregningsvirksomheten til ? bli et "regnekontor" og midt p? 1950-tallet en "matematikkseksjon" med mange dyktige folk, blant annet Ole-Johan Dahl , som i likhet med Garwick ble meget dyktig i programmeringsspr?k. Nygaard gikk over i operasjonsanalyse (planleggingsforskning) og ble spesialist i milit?rteknologiske strategi- og taktikkstudier. I det feltet fikk han p? ny bruk for simuleringsmetoder, der simuleringen etterapet adferd av v?pensystemer i konflikt.

N? var de f?rste brukbare datamaskinene kommet, men det var meget vanskelig ? lage feilfrie simuleringsprogrammer. Nygaard begynte ? leke med tanken p? ? lage et programmeringsspr?k for simuleringsoppgaver. Men han oppdaget at det han f?rst og fremst trengte, var et spr?k med begreper og uttrykksformer som kunne brukes til ? fastholde og forst? meget komplekse systemer, med mange komponenter i kompliserte samspill. Et slikt spr?k skulle brukes til ? beskrive og kommunisere om slike systemer.

I 1960 kom Nygaard til Norsk Regnesentral for ? utvikle operasjonsanalyse, elektronisk databehandling, anvendt matematikk og statistikk for sivile form?l og bygge opp Norsk Regnesentral til et forskningsinstitutt. Det varte ikke lenge f?r han igjen fikk oppgaver som krevde simulering. Denne gangen bestemte han seg for ? fors?ke ? lage et spr?k som b?de kunne v?re et spr?k for systembeskrivelse og for programmering, slik at systembeskrivelsen via et oversetterprogram kunne lage et simuleringsprogram for det systemet som ble beskrevet. Spr?ket fikk tidlig navnet SIMULA (for SIMUlation LAnguage).

Nye moderne spr?k

- Vinteren 1962 presenterte jeg ideene for min venn og kollega Ole-Johan Dahl. Han hadde det jeg manglet av kompetanse innenfor programmeringsspr?k, og n? startet den fruktbare prosessen som skulle munne ut i f?rste versjon av SIMULA i 1965. Mange har spekulert p? hvordan vi jobbet sammen og hvem som "eier" hvilke deler av SIMULA. Men det er umulig ? splitte SIMULA, det er et produkt vi har laget sammen.

Ole-Johan Dahl ble i 1968 den f?rste informatikkprofessor ved Universitetet i Oslo og ble den sentrale i oppbyggingen av det som i dag er Institutt for informatikk. Faglig gikk han videre i teoretisk informatikk, med programbevisf?ring som hovedinteresse. Kristen Nygaard har fortsatt arbeidet med objekt-orientert programmering, blant annet med det meget moderne og generelle spr?ket BETA, sammen med danske forskere. Dessuten har en viktig del av forskningen hans ligget innen feltet systemarbeid. I dag arbeider han med utvidelser av slagkraften for objekt-orientert programmering til distribuerte og lagdelte systemer. Det skjer innen prosjektene GOODS og STAGE ved Institutt for informatikk og Norsk Regnesentral.

Liten hjelp fra NTNF

- Burde Norsk Regnesentral og Norges teknisk-naturvitenskapelige forskningsr?d (NTNF) ha lagt st?rre vekt p? ? spre SIMULA, blant annet ved ? gi det en mer overkommelig markedspris?

- Ja, med skam ? melde, jeg synes s?rlig at NTNF h?ndterte den siden av saken p? en lite imponerende m?te. Der hevdet man at prisen for SIMULA m?tte settes slik at alle kostnader ble dekket inn meget raskt: Programmeringsspr?k levde ikke lenger enn tre til fem ?r, ble jeg fortalt. Dette var det rene t?v. Jeg mente at programmet burde deles ut gratis til universiteter og andre vitenskapelige institusjoner, og at prisen til privatkunder burde kunne v?re mindre enn den halve av hva som ble krevet, sier Nygaard og trekker en episode opp av hukommelsen:

- Donald Knuth, en kjent dataforsker ved Stanford, jobbet en tid i Norge. Da han skulle reise hjem, spurte han om han kunne f? med seg SIMULA for ? bruke det som oppl?ringsspr?k ved Stanford. Jeg la inn et ord for ham, men han fikk nei. Han skulle betale en sum som var langt st?rre enn den han hadde til r?dighet. Det kaller jeg inkompetanse, sier Nygaard.

- Dere fikk ingen s?rlig st?tte fra omgivelsene?

- Vi fikk god st?tte for SIMULA-utviklingen fra ledelse og styre i Norsk Regnesentral. Ellers mente folk at a) det var uinteressant, b) det var interessant, men det var gjort f?r, c) Ole-Johan og jeg ikke var kompetente for oppgaven, og d) slikt ikke burde utvikles i et lite land som Norge, sier professor Kristen Nygaard som i begynnelsen av februar ble hedret med ROSING-prisen - nettopp for SIMULA.