Logg #008 (Dato: 29.09.42)

Hei igjen folkens. En liten stund siden forrige logg n?. Det er det en veldig enkel grunn til; jeg har stanga hodet i kode. Vi har jobbet med ? f? til et dataprogram som kan regne ut hvordan sonden v?r vil bevege seg p? veien til m?let. Vi har forresten bestemt oss for hvor vi skal! Vi skal til v?r n?rmeste nabo, planeten som har bane like utenfor v?r egen. Den heter Kessel, og vi skal forklare senere hvorfor vi valgte akkurat denne planeten av alle de andre planetene i systemet v?rt.

Men tilbake til koden. For ? simulere hvordan noe beveger seg i verdensrommet trenger man egentlig ikke ? vite s? mye; alt du trenger ? vite noe om er kreftene som virker p? det du skal simulere. For v?r sonde er det da snakk om gravitasjonskrefter. I verdensrommet er det ingen andre krefter som har noen merkbar effekt p? et objekts bevegelse p? den skalaen vi ser p?. Gravitasjonskreftene kan deles inn i to grupper; gravitasjonskraften fra stjernen (som dominerer) og fra planetene (som kun f?r noe s?rlig effekt om objektet havner veldig n?r en av disse). Derfor er det disse kreftene vi m? simulere mens vi lar sonden v?r fly gjennom rommet.

Grubleoppgave:

Figur 1

En fantastisk tegning (tja) av en satellitt som p?virkes av gravitasjonskrefter fra en stjerne og en planet. Kan du se hvor satellitten befinner seg i forhold til stjerna og planeten? Her er tre alternativer (fasit st?r nederst):

a)                                             b)                                         c)

Her er stjernen den store "sirkelen" og planeten den minste. St?rrelsesforholdene er ikke proporsjonale i tegningene, s? det er kun posisjonen til sonden, og derfor retningen til kreftene vi ser p?.

Vi begynner med ? hente fram en del data fra de tidligere programmene og simuleringene vi har gjort. Vi trenger ? vite hvor vi er i forhold til stjerna, hvor fort vi beveger oss gjennom verdensrommet og i hvilken retning, ved starten av reisen. Dette henter vi fra den simuleringen vi gjorde av rakettoppskytningen v?r. I tillegg trenger vi ? vite hvor hver av planetene i solsystemet v?rt er til enhver tid. Dette henter vi fra v?r numeriske beregning av planetbanene. Da har vi alle initialverdiene vi trenger for ? begynne ? gj?re baneberegninger.

Vi har lovet at vi ikke skal snakke s? mye om kode, s? istedet for ? lime inn et utsnitt av koden v?r skal jeg pr?ve ? forklare hvordan den fungerer. Vi skriver f?rst en funksjon for ? beregne akselerasjonen til sonden v?r gitt et tidspunkt. Vi bruker newtons gravitasjonsformel for stjernen, som sier at akselerasjonen til sonden er lik gravitasjonskonstanten ganget med massen til stjerna delt p? avstanden mellom stjerna i annen, i retning mot stjerna. Deretter bruker vi egentlig akkurat samme formel bare med massen til hver planet og, avstanden og retningen, til planetene for ? regne ut akselerasjonen fra hver av dem. Til slutt summerer vi opp alle disse verdiene og retningene til en total akselerasjon. Likningen ser da slik ut:

Der G er gravitasjonskonstanten, \(M_*\) er massen til stjerna, \(r_*\) er avstanden fra stjerna til satellitten, \(M_{p,i}\) er massen til planet nummer i, \(r_{p,i}\) er avstanden fra planet nummer i til satellitten og N er antallet planeter. Hos oss er \(N=8\).

N? tenker jeg at jeg skal beskrive den viktigste metoden vi bruker til ? gj?re numeriske beregninger av bevegelser. Den heter Euler-Chromer-metoden, og bruker det som kalles differenslikninger i diskrete tidssteg (beklager om det ble litt mange uttrykk, jeg skal forklare dem straks). Jeg begynner med ? si hva "diskrete tidssteg" egentlig vil si. Vanligvis tenker vi at tid er noe som er kontinuerlig, vi kan alltid dele den opp i mindre og mindre biter, til s?kalte infinitesimale biter som er uendelig sm?. Dette er ikke mulig n?r man skal simulere noe p? en datamaskin. Da m? man gj?re en ny beregning for hver bit av tid som g?r, og det ville jo blitt uendelig mange hvis "tidsbitene" var uendelig sm?. Derfor deler man tiden opp i sm?, men endelige, biter kalt tidssteg, dt eller \(\Delta t\) (les "delta t", som betyr endring i tid). I simuleringen regner man ut hvordan systemet ser ut i tidssteg "i" og s? bruker man det til ? si noe om tidsteg "i+1". Alts? n?r man har g?tt ett tidssteg videre ("i" er bare et heltall som sier noe om hvor du er i tidsforl?pet). Dette bringer oss fint over til differenslikninger. Dette er likninger som regner fra steg "i" til steg "i+1". I Euler-Chromer ser likningssettet slik ut:

Den ?verste linjen er ikke en differenslikning, men brukes i likning 2 og 3. Den regner ut akselerasjonen gitt ved newtons gravitasjonslov og newtons andre lov (han dukker stadig opp han der Newton ...). Den neste linjen bruker farten (\(v\)) fra forrige tidssteg (i) og akselerasjonen til ? regne ut farten i neste tidssteg (i+1). Her er dt lengden, eller forskjellen, mellom to av de diskrete tidsstegene. Den tredje linjen bruker posisjonen (\(s\)) i forrige tidssteg (i) og den farten for neste tidssteg som ble regnet ut i linjen over til ? regne ut posisjonen i neste tidssteg. Deretter gj?r du dette for neste tidssteg, og s? neste, og neste, og s? videre ... Det fine med differenslikninger er at om du f?rst vet hva akselerasjonen, hastigheten og posisjonen er i ett tidssteg kan du regne deg fram eller tilbake og finne alle tre for alle andre tidssteg.

Euler-Chromer-metoden er en videreutvikling av Eulers metode. Eulers metode kommer fra l?sningen av differensiallikningen for bevegelse som dere enten har sett f?r eller kommer til ? se i Fysikk 2. Differensiallikningen ser slik ut:

Og man kan l?se dette med hensyn p? v og s, og finne ut at 

og

Har du sett det f?r? Uansett om du har sett det f?r kan du kanskje se at de siste to leddene i den siste likningen er det samme som h?yre siden i den forrige likningen bare ganget med t. Det er dette som skiller Eulers metode og Euler-Chromer-metoden. I Euler bruker man likningene som de st?r over p? formen:

mens i Euler-Chromer-metoden, som er vist litt lengre opp p? siden, har man satt likning to inn i likning tre og dermed forenklet regningen litt. I tillegg viser det seg at Euler-Chromer-metoden er litt mer n?yaktig enn Eulers metode. Og det er fint n?r man skal regne p? ting som skjer over lang tid.

Okey, jeg h?per dere n? har en id¨¦ om hvordan dette fungerer (husk at det er lov ? stille sp?rsm?l i kommentarene om det er noe du lurer p?). Vi bruker dette mye n?r vi skal regne p? hvordan ting beveger seg. Og sonden v?r skal jo bevege seg gjennom solsystemet v?rt.

? implementere dette som kode er imidlertid ikke alltid s? enkelt. Jeg st?tte p? et problem n?r jeg skulle bruke Euler-Chromers metode for ? regne ut banen til sonden v?r etter vi hadde skutt den opp fra Gallifrey. Det viste seg nemlig at de tidsstegene jeg trengte for ? f? en n?yaktig nok beregning av sondebanen var mye mindre enn de vi brukte n?r vi beregnet planetbanene. Dette er problematisk fordi jeg trenger ? vite hvor planetene er i det tidspunktet jeg ser p? i sondebaneberegningen for ? regne ut akselerasjonen riktig. Jeg m?tte derfor finne en tiln?rmet (omtrentlig) posisjon mellom hvert av de tidsstegene vi hadde beregnet i planetbaneberegningene v?re. Det jeg gjorde var ? uttrykke det tidssteget i sondebaneberegningen som jeg ville vite noe om som et desimaltall ganget med et tidssteg fra planetbaneberegningen. Dermed kunne jeg finne gjennomsnittsfarten mellom planetposisjonen i tidssteget f?r og etter, og s? gange med desimaldelen av tidsuttrykket. La meg gi et eksempel og en figur:

I dette tilfellet vi jeg vite hvor planeten er ca. en tredjedel mellom tidssteg 1 og tidssteg 2. Da bruker jeg posisjonen i tidssteg 1 og posisjonen i tidssteg 2 til ? finne en gjennomsnittsfart (eller vektoren fra posisjon 1 til posisjon 2) og ganger med 0,3 for ? finne posisjonen jeg er ute etter (den stiplete planeten). I neste del vil jeg kanskje gange med 0,4 og s? 0,5 og s? videre.

N?r jeg f?rst hadde funnet ut av dette var det bare ? legge inn det jeg allerede visste om startposisjon og starthastighet etter utskytningen og bruke Euler-chromer-algoritmen til ? beregne sondebanen. Med de forel?pige testverdiene vi har ser den s?nn ut:

Der sirklene er planetbaner (ikke alle planetbanene er hele sirkler. Det er fordi disse planetene ikke rekker ? gj?re en hel runde rundt stjerna i l?pet av den tiden jeg simulerer). Den bl? banen som g?r fra den innerste sirkelen og litt ut forbi den nest innerste er sondebanen v?r. Den kommer til ? endre seg n?r vi begynner ? finjustere n?r og hvor vi skyter opp fra, slik at vi treffer p? planeten vi skal til.

Det var alt for denne gang. Det kommer nok noen flere innlegg snart.

- NLO Gustav

Fasit grubleoppgave:

Sonden m? v?re i posisjon c):

Fordi her ligger sonden mellom planeten og stjernen og da peker gravitasjonskreftene i motsatte retninger slik som i figur 1.