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.
(╯°□°）╯︵ ┻━┻