M?ten vi gj?r dette p? er ganske lik m?te vi gjorde tidligere n?r vi skulle skyte opp, nemlig simulere slik vi tror ting kommer til ? g?. N? som vi har en modell av hvordan planetene endrer posisjon s? m? vi faktisk simulere at planetene endrer posisjon igjen og igjen og igjen. Vi vil at planetene skal endre posisjon litt og litt til alle planetene har i hvertfall kommet hele veien rundt, men her kan nok ting begynne ? bli un?yaktige om vi ikke er forsiktige.
Vi tenker at vi m? se at vi har ting litt p? plass her; si vi f.eks. skal regne ut hvordan et legemet forandrer posisjon én gang. Det vi har n? er en starthastighet og en startfart, vi kjenner til dette uttrykket for fart $v = \frac{s}{t}$ s? la oss pr?ve ? utvide p? dette litt.
\(v = \frac{s}{t}\)
$s = v \cdot t$,
der $s$ er distanse, $v$ er fart og $t$ er tid.
Dette gir da mening, men kan vi generalisere litt mer for hvordan posisjonene endrer seg n?r tiden endrer seg?
$\Delta s = v \cdot \Delta t$
Yes, dette ser bra ut. Med dette uttrykket kan vi regne ut hvordan posisjonen endrer i simuleringen, men det blir vel kanskje ikke s? n?yaktig hvis vi ikke gj?r noe med den $v$-variabelen ogs?. Farten vil vel ogs? endre seg ganske likt slik posisjonen endrer seg. Vi f?r dermed
$\Delta v = a \cdot \Delta t$
$\Delta s = v \cdot \Delta t$
Denne simuleringen tenker vi m? regne ut de nye posisjonene og hastighetene flere ganger, alts? flere iterasjoner. Vi kaller hver av disse regnesekvensene, eller kanskje enklere ? tenke seg det som tidssteg i modellen, som iterasjoner. Hvis vi generaliserer det og sier at vi skal regne p? iterasjon nr. $n$ s? kan vi kalle variablene v?res for $s_n, v_n, a_n, t_n$, og hvis vi g?r et steg videre kan vi skrive det slik:
$s_{n+1} = s_n + \Delta s$
$\Delta s = v_n \cdot \Delta t_n$
$v_n = a_n \cdot \Delta t$
Alts? vi f?r
$v_n = a_n \Delta t$
$s_{n+1} = s_{n} + v_n \Delta t$
Alt dette h?res vel veldig kjent ut. Hmm.
$s = C + s’$
Ja selvf?lgelig, det vi holder p? er jo bare en differensiallikning. Denne differensiallikningen klarer vi nok ikke ? l?se analytisk for h?nd, dessverre. Men heldigvis kan vi klare det ved hjelp av datamaskiner som numerisk l?ser dem slik med disse iterasjonene vi har nettopp g?tt over. Men for ? l?se slike differensiallikninger s? har vi ogs? andre metoder. Metoden vi formulerte n? er faktisk en godt anerkjent metode for ? numerisk l?se differensiallikninger, den kalles Eulers metode. Men som du kanskje allerede vet eller har skj?nt, s? vil ikke alltid denne metoden gi oss s? n?yaktige resultater, spesielt etter mange iterasjoner.
Dette bildet viser veldig godt hvordan en slik numerisk beregning kan etterhvert gi oss mer og mer un?yaktige svar. En m?te vi kan l?se dette p? er ? ha flere tilfeller der vi evaluerer neste verdi, alts? flere iterasjoner per tid. Ved ? bruke mindre tidssteg kan vi f? en mer n?yaktig modell men den vil allikevel drifte(stadig f? tillegger) med denne metoden n?r vi har g?tt gjennom nok iterasjoner og ikke kan senke tidssteget p? grunn av datamaskines grenser. N?r vi skal simulere de fulle banene til hver av planetene inneb?rer dette at de ytterste planetene i systemet vil naturligvis bruke veldig lang tid s? vi m? virkelig simulere over lang tid.
Vi vil da ende opp med en bane som ikke vil ende der den startet men heller spirallere utover.
Leapfrog
Det er flere m?ter ? l?se dette problemet p?, eller dvs m?ter ? gj?re det mer n?yaktig, og de fleste m?ter inneb?rer ? bruke en annen metode. Det finnes mange metoder der ute for ? l?se differensiallikninger, mange er versjoner av Euler og mange er laget for ? l?se spesifikke typer likninger. En spesielt god metode for det vi skal l?se/simulere er metoden Leapfrog. Leapfrog fungerer, i motsetning til Euler, ved at den deler opp alle iterasjonene inn i to deler der den bytter mellom ? beregne posisjonen og farten.
$x_{n+1} = x_{n} + v_{n + \frac{1}{2}} \Delta t$,
$a_{n+1} = F(x_{n+1})$,
$v_{n + 3/2} = v_{n + \frac{1}{2}} + a_{n+1} \Delta t$
Disse oppdelingene Leapfrog har gj?r at feilen vi ellers ville f?tt ved Euler blir tiln?rmet nullet ut av seg selv. Dette gj?r ogs? at vi f?r noen andre fordeler som at vi kan alltid g? bakover i algoritmen og havne n?yaktig der vi startet. Dette betyr ogs? at den garanterer konservering, som konservering av energi, konservering av vinkelmoment og alt annet vi kunne forvente fra en perfekt modell. Dette er veldig bra for v?r del n?r vi skal faktisk teste at vi har klart ? gj?re dette riktig. Etter vi har simulert s? m? vi ogs? kontrollere banene p? noe m?te og dette blir mye enklere n?r vi har energien konservert.
Dette er banene vi f?r etter ? ha simulert litt over en full bane p? den ytterste planeten. Den simulerte tiden er n?yaktig 100 ?r, vi tenker det burde gi oss mer enn nok data.
N?yaktighet:
Det er ingen hemmelighet at numerisk integrasjon ikke gir oss et n?yaktig svar, s? for ? f? bruk for dataen man f?r fra en simulering s? m? man vite n?yaktigheten. Uten n?yaktigheten er dataen praktisk talt ubrukelig fordi for alt man vet kan den v?re gigantisk. Selvom det er vanskelig ? finne posisjonen til planetene som funksjon av tid analytisk, s? er det enkelte egenskaper til banen vi kan teste mot analytiske formler. Ved ? for eksempel teste Keplers lover opp mot den numeriske dataen v?r. Om man estimerer korte og lange halvakse til banene kan man anvende den generelle formelen for en ellipse til ? se hvor langt unna formen p? banen er fra de forventede verdiene.
En annen m?te er ? sjekke opp mot Keplers 2. lov. Man kan finne arealet vektoren sveiper over i et tidsintervall ved ? summere sammen arealene fra hvert enkelt tidssteg i integrasjonen slik som vist i figur 3.
Siden disse tidsstegene er utrolig sm? og planeten er veldig langt unna sola er det en god tiln?rming ? si at arealet danner en rettvinklet trekant, og vi kan derme finne arealet for hvert tidssteget ved: $A_i=\frac{|\vec{r}(t_{i+1})-\vec{r}(t_{i})|\cdot|\vec{r}(t_{i})|}{2}$
$A=\sum_{i=0}^NA_i$
hvor $N$ er anntall tidssteg.
Keplers 2. lov sier at dette arealet skal v?re likt uansett hvor i banen du m?ler det, men p? grunn av feil i numerisk integrasjon vil man det ikke bli det for den genererte dataen v?r. Men n?r man endringen i areal, s? kan man finne den relative feilen til simuleringen sammenlignet med hva man forventet.
Logg inn for ? kommentere