Fysikksimulering: Generelle prinsipp

Vi skal sjå litt på prinsippa bak simulering av mekaniske system, dvs. anvendelsar av Newtons lover++.

Animasjon vs Simulering

Begrepa animasjon og simulering er ikkje veldefinerte, men dette er eit forsøk på avgrensing. Wikipedia seier at ein animasjon er  ein "illusjon av bevegelse som oppstår når en viser stillestående bilder fortløpende etter hverandre". Eksempel på dette er ein tegnefilm. Og som vi alle veit behøver ikkje ein tegnefilm å vera eingong i nærheten av verkeligheten! Simuleringar prøver derimot alltid å modellera verkeligheten i større eller mindre grad. Ein animasjon kan altså vera ein simulering, men veldig ofte er den ikkje det. På same måten kan ein simulering vera animert, men den behøver ikkje vera det. Noken gonger vil vi bare rekna ut verdiar (av td. fart og posisjon til ein satelitt) for å plotta dei i ein graf, eller analysera data vidare. Men andre gonger vil vi sjå korleis bevegelsen ser ut, og det er det vi skal sjå på her.

Animasjonar kan altså vera realistiske. Men i den grad dei prøver å vera det, så vil dei ofte heller imitera resultata eller effekten av dei fysiske lovene, enn å imitera lovene direkte. Eksempel: Hvis vi vil laga ein enkel animasjon for ein satelitt som går i sirkelbane rundt jorda, så treng vi bare skriva posisjonsvektoren som ein funksjon av t: r(t)  = [(r cos(kt), rsin(kt)], og så oppdatera t. I dette tilfellet har vi altså funksjonsutrrykket. Men vi kan også simulera bevegelsen, ved å ta utgangspunkt i gravitasjonsloven og Newtons andre lov, og rekna ut bevegelsen iterativt (steg for steg). Hvis vi også passar på å starta satelitten med korrekt posisjon og korrekt fart, så ser vi at den faktisk går i ein sirkelbane. Med andre startbetingelsar vil den gå i ein meir avlang ellipsebane, evt. i ein parabel- eller hyperbelbane. Så denne måten å simulera er meir generell. Vi treng ikkje endra anna enn startbetingelsane for at vi skal sjå alle mulige banar for eit system av to objekt, som her. Men den store fordelen er at vi på same måten kan simulera bevegelsen til tre eller fleire objekt, i situasjonar der funksjonsuttrykka ikkje er kjent. Med andre ord: dett er det einaste måten å simulera trelegemeprobem. Vi skal no sjå litt nærare på korleis strukturen til slik simulering. Så dette blir vårt rammeverk, som kan brukast for mange ulike situasjonar.

Ein generell algoritme 

Initier verdiar. I simuleringar, som i all annan programmering, er det lurt å starta med å definera alle konstantane som for systemet, som feks. den universelle gravitasjonskonstanten osv. I tillegg treng vi å gi startverdiar til alle variablane som inngår, som tid, posisjon, fart mm. I dei aller fleste tilfelle vil også massane til gjenstandane vera konstante. Rakettar er eit unntak, sidan dei kan mista betydelig masse i løpet av kort tid.

Løkke: I verkelighetens verden beveger ting seg gjennom rommet kontinuerlig, og dei blir påvirka av krefter heile tida. Men i ein datamaskin har vi ikkje mulighet til å modellera kontinuerlig tid. Så vi deler derfor  tidsaksen opp i korte intervall Δt, og så prøver vi å rekna ut aktuelle størrelsar som krefter, akselerasjon, fart og posisjon for kvart tidspunkt t0, t1, ved hjelp av ei løkke. Vi vil som regel då enten ta vare på verdiane for å plotta grafar, eller vi vil animera bevegelsen vha. Pygame eller andre verktøy. Inne i løkka må vi gjera følgande: (steg 1 til 5)

1) Rekn ut kreftene på kvart objekt: Det første vi gjer inne i løkka er å rekna ut alle kreftene som virkar på kvart objekt. Deretter kan vi summera x-, y- og z-komponentane til alle kreftene og finna vektorsummen F = [Fx, Fy,Fz] på kvart objekt. Vi kan også bruka andre typer koordinater, som kulekoordinater. Hvis massen til objektet (typisk ein rakett) endrar seg, så må vi også her rekna ut ny verdi.

2) Finn akselerasjonen til kvart objekt. Newtons andre lov på vektorform er F = ma. Her er F og a vektorar i 3D. Når vi snur på denne formelen, så finn vi akselerasjonen i x-, y- og z-retningane:

Hvis vi gjer 2D-simuleringar, vil vi bare bruka x og y. Dette gjer vi normalt inne i løkka. Unntaket er hvis summen av kreftene er konstant, som for eksempel i eit fritt fall. Då kan vi rekna ut vektor a ein gong for alle utanfor løkka. I fritt fall får vi az = g, mens ax og ay er null.

3) Finn fart og posisjon for kvart objekt. Så langt vil feilen i våre utrekningar vera eit resultat av usikkerheten i målingane og unøyaktighet i korleis vi modellerer kreftene. For eksempel er luftmotstand vanskelig å modellera med stor grad av nøyaktighet, mens gravitasjonskrafta kan modellerast mykje meir nøyaktig. Begrensingar i antall siffer som datamaskinen kan rekna med gir også opphav til feil. Men no introduserer vi ein feil som har med metoden vår å gjera. Den enklaste metoden, som også gir størst feil, er å tenkja som følger: Hvis vi reknar over korte nok tidsintervall Δt, kan vi setja momentanakselerasjonen lik gjennomsnittsakselerasjonen. Dette er altså ein tilnærming, men den vil ofte fungera bra. Vi har altså:

a = Δv/Δt. Når vi set Δv = vn+1 - vn, multipliserer med Δt, og ordnar, så får vi at  vn+1 = vn + a*Δt

På same måte set vi momentanfarten lik gjennomsnittsfarten: (nok ein tilnærming, altså)

v = Δx/Δt. Når vi lar Δx = xn+1 - xn , og multipliserer med Δt og ordnar likninga så får vi:  xn+1 = xn + vn+1*Δt

Merk at disse to formlane er på vektorform. Så kvar av dei har tre (eller to) komponentar. Dette er den enklaste metoden å rekna ut fart og posisjon på, og kallast Eulermetoden. Det fins meir nøyaktige metodar, men for vårt formål er Eulermetoden bra nok. Kva er så ein "liten nok" Δt? Det kjem an på problemstillingen. For for noken applikasjonar vil det vera mindre enn eit sekund, mens for vår satelitt-simulering kan det vera over eit minutt. Med for stor Δt, vil vi sjå at banen blir langt frå ein sirkelbevegelse.

4) Detektering og behandling av kollisjonar. For kvar iterasjon kan vi ha behov for å sjekka om objekta våre har kollidert eller er i ferd med å kollidera. Då må vi ha kode som korrigerer fartsvektoren og posisjonsvektoren. Problemet er for det første at kollisjonar ofte skjer veldig fort, og for det andre at har vi gjerne ikkje ein god modell for kreftene i kollisjonen. Derfor vil vi ikkje i dette kurset simulera fysikken i ein kollisjon, men bare effekten. Hvis vi for eksempel modellerer ein ball som treff ein vertikal vegg, så kan vi modellera det som om kollisjonen skjer frå eit klokketikk til det neste. Så neste t snur vi x-komponenten til farten. I tillegg kan vi redusera farten for å simulera uelastiske kollisjonar. For ein fullstendig elastisk kollisjon vil ballen bli hengande fast i veggen, slik at vx = 0. I ein satelitt-simulering vil ein kollisjon gjerne innebera at vi stoppar animasjonen, for det betyr jo at satelitten har styrta.

5) Flytt alle objekt. Når vi lagar ein animert simulering vil vi flytta dei, dvs tegna dei i den nye posisjonen, og dette må vi gjera for klart klokketikk. Hvis vi derimot bare skal plotta kurvane som ein graf, så må vi ta vare på alle posisjonane og plotta dette først når alle er rekna ut.

Korfor laga ein simulering når ein animasjon fungerer like bra?

Så kan ein innvenda at hvis ein bare skulle simulera ein sirkelbevegelse, korfor tar vi oss då bryet med alle disse utrekningane? Og svaret er sjølsagt at det er ikkje nødvendig, og spesielt med tanka på at animasjonen vår gir eit eksakt svar, mens simuleringen bare gir eit tilnærma. Men straks vi for eksempel simulerer tre eller fleire objekt under påvirkning av gravitasjonskrafta (dvs. trelegemeproblemet), så er det ikkje mulig å rekna ut banane deira på forhånd. Då er vi nødt til å simulera stegvis. Og mange dyktige fysikarar og matematikarar har jobba (og jobbar fremdeles) med å forbetra metodane og algoritmane for å få så gode svar som mulig. På den andre sida er det veldig nyttig å simulera sirkel- og ellipsebanar, fordi vi har den eksakte løysinga som vi kan samanlikna med.