Vi kan starte med å se på litt generell informasjon om planetene først, før vi går løs på programmeringen. Det er noe som er relevant men utenom det er det mest for nysgjerrighetens skyld. Solsystemet vi befinner oss i er nemlig meget interessant sammenlignet med mange andre.
La oss starte med den første av tre elefanter i rommet, nemlig størrelsene på banene. Alle banene er generelt sett store, for ikke å nevne at det bruker lang tid på å gå rundt solen. Dette viste seg å bli et av problemene vi kom borti.
Den andre elefanten er vår egen stjerne, den er massiv, så og si 4 ganger så massiv som vår egen sol, i tillegg er den også 2.89 ganger større radius enn solen sin radius.
Så har vi den tredje og siste elefanten i rommet, vår største planet. For å si det sånn, den er stor, og er rundt halvparten så massiv som den teoretiske grensen for en stjerne skal ha før de klarer å oppnå fusjon i kjernen, med andre ord det som skal til før vi har noe vi kan kategorisere som en stjerne.
Vel, nok snakk om vårt underlige solsystem, for det skal vi studere nærmere litt senere. For enkelhetens skyld vil jeg referere til det simulerte solsystemet sin stjerne som 'stjerne', og vår egen sol som 'sol'.
Så vi startet først med å finne periodene til alle planetene, dette gjorde vi gjennom å bruke en litt annen versjon av kepler sin formel. Vanligvis er formelen for perioden gitt som \(P^2 = a^3\) der \(a\) er semi major av ellipsen. Denne holder ikke for oss, for det viste seg at det var nesten riktig. Kepler hadde ikke presise nok data til å finne ut av at perioden er avhengig av massen til planetene, for solmassen er så mye større i forhold til planet massene at det nesten ikke merkes. For oss blir perioden derfor \(P^2 = \dfrac{4\pi^2}{G(M_{sol} + m)}a^3\), som ble brukt for å finne periodene. Dette ble gjort fordi vi ville nemlig simulere bevegelsen til planetene over 20 ganger perioden av vår egen planet rundt stjernen. Det viste seg at vår planet bruker 10.4 jord år for å gå rundt stjernen så da ville vi ha simulert over en tid som tilsvarer ca 208 år.
Mellom dette plottet vi også den analytiske løsningen der vi bare hentet den informasjonen vi trengte for å kunne plotte det. Dessverre var det ikke så mye vi kunne gjøre uten å plotte det, på grunn av tiden. Så det å bekrefte at vi hadde plottet riktige former var ikke så vrient, det som var mer vrient var å vite om vi hadde rotert dem riktig vei. Litt vanskelig når man ikke har noen andre indikasjoner å sammenligne med.
Noe vi vil nevne med en gang er at vi ikke fikk helt til å få bekreftet presisjonen på vår simulering, og ble derfor nødt til å få hjelp fra andre vesener som lever i et høyere plan enn det vi klarer å forstå. Så vi vil gå igjennom det som var planen og vil også gå igjennom potensielle grunner til at vi ikke fikk det helt til.
Vi brukte en annen numerisk metode som heter leapfrog, grunnen til dette var at den har noen egenskaper vi ønsker som de forrige, vanlige euler og euler cromer, ikke har, som er at denne bevarer de geometriske formene. Kort forklart så betyr det at det bevarer energien til et system i langt større grad enn de forrige metodene, og for ellipser er dette en stor fordel. Selvfølgelig er det ingen metoder som klarer dette 100% så formene vil sakte men sikkert endres utover en simulasjon. Dette er noe vi fikk problemer med, som vi kommer innpå. En annen egenskap er at man kan også kan starte på slutten og gå baklengs og fremdeles få samme resultat. Dette er noe vi ikke brukte for vi gjorde ting fra starten og i en kronologisk rekkefølge.
Vi forholdt oss til enhetene AU for avstand, AU/yr for fart og masser i forhold til solmasser, og yr for tid. AU er astronomiske enheter som er avstanden jorden er fra solen, som er rundt 150 * 109m, yr = antall sekunder i et år. Gravitasjonskonstanten ble også da \(G = 4 \pi^2\). Grunnen til at vi bruker disse enhetene er at ting i verdensrommet er så stort at det blir problematisk når man skal forholde seg til SI enheter som kan skape sine egne problemer under en numerisk utregning.
Måten vi flyttet på objektene var mye av det samme som med euler cromer, finn kraften, og beveg objektet ut ifra en rekke sekvenser. Her er kraften det mest interessante eller relevante. Vi tok utgangspunkt i at stjernen var stasjonært i sentrum, det vi definerte som origo. Deretter brukte vi Newtons gravitasjonslov, mellom stjernen og hver av planetene. Vi er ute etter kraften fra stjernen på planetene, der kraften på planetene er massen ganget med akselerasjonen. Formelen for Newton's gravitasjonslov gjør at massen for planeten kan bli fjernet og det vi står igjen med er akselerasjonen. Deretter må vi huske retningen kraften pekte, så på grunn av at dette er i motsatt retning av det planeten ellers ville bevege seg i så setter vi et minus tegn foran og dermed har vi uttrykket vi ønsket.
Vi startet først med å definere et tidssteg som tiden planeten bruker rundt stjernen så delte vi det på antall steg vi ønsket som vi kalte for n. Vi hadde også gjort om til vanlige SI enheter for å være på den sikre siden. Så kjørte vi dette sammen med start posisjonene til planetene, og initial farten i i x og y retning. Deretter skulle vi bekrefte at vi hadde den presisjonen vi trengte. Presisjon av baner er utrolig viktig når det kommer til navigering ute i verdensrommet. Dersom du er bare så vidt ute av kurs kan du fort bomme på målet. Et godt eksempel er under månelandingen, astronautene måtte stadig finne ut av hvor de var i forhold til månen, og da brukte de var det å se ut på stjernene og bruke det til å navigere seg med. Man er fremdeles nødt til å kunne vite hvor en er til enhver tid når man skal sende romsonder ut på oppdrag, for det er veldig kjipt å rote bort maskiner verdt millioner. Presisjonen ble bestemt ut ifra hvor stort avvik den simulerte banen var i forhold til den faktiske banen, vi trengte en presisjon på 1%. Så da sendte vi posisjonene fra simuleringen for å få vite hvor stort avvik vi hadde, og resultatet var ikke det vi ønsket.
Avvik på ca 218% og mer. Noe hadde gått galt, så vi startet med å se på banene, og så at noen av dem ikke beholdt sin geometriske form slik det skulle, så vi sjekket om måten vi hadde definert akselerasjonen på var feil, noe det ikke var.
På tide å gå igjennom sjekklisten for feilsøking.
Vi startet med å se på fysikken og matematikken bak implementeringen, dette var riktig, og ikke noe å finne der. Deretter gikk vi til leapfrog, å så om den var implementert riktig, noe den var. Vi senket størrelsen på tidsstegene, og det hjalp noe, så da var det noe med tidsstegene å gjøre, men det kunne, og var ikke, alt. Vi endte med å gå tom for minne, før vi fikk det ned til 1%, sånn sett skulle vi ikke ha trengt noe mer enn rundt n = 10 000, muligens litt mer. Dette her nærmet seg å bli latterlig.
Ok, ingen åpenbare feil med det mest vanlige tingene. Vi gjorde så alt om til den initial enhetene sine, og prøvde igjen, hjalp ikke så mye. Så da sendte vi noen bønner til noen vesener som eksisterer i et høyere plan enn oss og fikk til å vurdere arbeidet. De rapporterte om noen mulige feil, så da gikk vi til verks å endret på dette. Første de nevnte var at vi ikke hadde definert noe start akselerasjon, så da la vi til det. 'har du sett, det løste problemet' er det vi ville si. Det gjorde ting bedre, med hele 0.001%.
Vi endret på hele koden for å kunne endre på måten vi definerte tidsstegene på, de trodde nemlig at det skulle være 1/n istedenfor. Vel, vi fikk det ned til rundt 65% med størrelse på dt = 10-5 før vi gikk tomme for minne igjen. Vi sjekket hvilken planet som ga problemer som var den innerste, denne gikk rundt stjernen dobbelt så mange ganger som det vår egen planet ville gjøre under simuleringen. Dette gjorde at den kom ut av sin posisjon langt raskere enn andre planeter.
Vi sjekket noe som kalles for avrundingsfeil som skulle ha blitt løst av å forandre tilbake til de gitte enhetene, men enkelte operasjoner gir fort avrundingsfeil dersom det gjøres mange nok ganger. Avrundingsfeil kommer av at vi gjør om mellom tallsystemer, der vi går fra titallssystemet til binært system for datamaskiner. Enkelte tall kan ikke bli representert presist i det binære systemet, og med begrenset mengde resurser fra datamaskinene sin side blir de nødt til å kutte av deler av tallet. Når utregninger gjøres vil dette kunne føre til avrundingsfeil fordi ikke presis representasjon av tall, men også fordi datamaskiner gjør det samme for hver enkelt grunnleggende regneoperasjon. Dette er et potensielt stort problem under numeriske løsninger som vi mest sannsynlig vil møte igjen.
En av operasjonene som kan lede til avrundingsfeil er når vi tar roten av et tall, som vi måtte gjøre. Så da implementerte vi i en testversjon en liten modul som skulle hindre dette til en viss grad ved å begrense antall desimaler som datamaskinen skulle bruke. Dette hjalp heller ikke. Det ble spekulert at det var avrundingsfeil eller noe annet som kalles for overflow, som er når datamaskiner regner ut tall de ikke lenger klarer å representere på grunn av fysiske begrensninger en pc har, som kunne være årsaken. Dette var definitivt ikke årsaken, for vi konkluderte med at overflow ville ha vært veldig lett å oppdage, og at avrundingsfeil kunne maksimalt ha vært ganske liten.
Ok, så det var ikke noe av de åpenbare feilene, eller de mer detaljerte årsakene heller, redusering av tidssteg økte presisjonen, men vi gikk tomme for minne. Implementasjonene og matematikken er også riktige, og ingen ting tyder på at noe annet har påvirket simuleringen.
Vi undersøkte litt og innså at mange andre systemer ikke hadde så lang periode. Det var også andre faktorer som hadde med solsystemet å gjøre som har ledet oss frem til å konkludere med at solsystemet vårt muligens krevde mer resurser enn det vi hadde tilgang til for å kunne simulere hvordan de bevegde seg. Vi prøvde også å splitte opp å simulere hver bane for seg, før vi samlet det, det gikk ikke. Så oppsummert, vi trenger bedre maskiner, eller så var det noe annet mindre åpenbart som lå bak det hele, alt fra måten verdier ble definert på, tidssteg, metoder til mulige forskjeller med systemene og programmer vi brukte.
Divine intervention måtte til, og dersom det ikke har vært åpenbart til nå, så måtte vi bruke en liten snarvei for å få den presisjonen vi skulle ha.
(╯°□°）╯︵ ┻━┻