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, mens andre gonger vil vi sjå korleis bevegelsen ser ut.

Animasjon 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: For å demonstrera bevegelsen til ei enkel planet som går i bane rundt sola, kan ein la planeta bevega seg langs ein ellipsebane. Dette er fordi at dei fysiske lovene for dette tilfellet (Gravitasjonsloven og Newtons andre lov) gir oss ei likning som kan løysast eksakt, og svaret er altså ellipsebevegelse som beskrivne i Keplers lover. Men Keplers lover er ikkje fundamentale fysiske lover. Dei er effekten av gravitasjonsloven som seier at tiltrekningskrafta mellom to lekamar er omvendt proporsjonal med avstanden mellom dei.

Dette såkalte tolegemeproblemet kan altså løysast generelt. Hvis vi vil modellera ein satelitt som går i bane rundt jorda, og vi er enige om at vi kan behandla dette som eit tolegemeproblem (Husk at då ser vi bort frå feks. både månen og sola sin påverkning, samt luftmotstanden. Alle disse kreftene vil vera små samanlikna med krafta frå jorda, men dei er ikkje null!), så treng vi egentlig ikkje simulera. Vi kan skriva posisjonsvektoren som ein funksjon av t: r(t)  = [(x(t), x(t)]. Men med ein gong vi bringer inn ein gjenstand til i problemet, så kan vi ikkje løysa likninga generelt. Då må vi bruka gravitasjonsloven direkte saman med Newtons andre lov, og rekna ut bevegelsen iterativt (steg for steg). Dette blir altså ei simulering.

Ein generell algoritme

Vi skal sjå litt nærare på korleis ein slik simulering kan fungera.

Initier verdiar. Ein simulering vil som regel starta med å definera alle konstantar som gjeld for systemet, som feks. den universelle gravitasjonskonstanten osv. I tillegg treng vi å gi startverdiar til alle variablane som inngår, som posisjon, fart mm. I dei aller fleste tilfelle vil også massane til gjenstandane vera konstante. Men 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. Vi må dela 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, gjennom ei løkke. Vi vil som regel då enten ta vare på verdiane for å plotta grafar, eller animera bevegelsen vha. Pygame eller andre verktøy. Inne i løkka må vi gjera følgande:

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 finn vi vektorsummen F = [Fx, Fy,Fz] av alle kreftene på kvart objekt. Ofte vil vi då summera x-, y- og z-komponentane til alle kreftene, men noken gonger vil vi bruka andre typer koordinater, som kulekoordinatert.

2) Finn akselerasjonen til kvart objekt. Newtons andre lov på vektorform er F = ma. Her er F og a vektorar i 3D. På komponentform blir dette

Når vi dividerer disse likningane på m, 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 vektorsummen 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 gravitasjonskraften modellert meir nøyaktig. Begrensingar i antall siffer som datamaskinen kan rekna med gir også opphav til feil. Men det vi kjem til no introduserer 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

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 dette bra nok. Kva er så "lite nok" for deltaT? Det kjem an på problemstillingen. For ei satelitt-simulering kan det vera over eit minutt, mens for andre applikasjonar vil det vera mindre enn eit sekund.

4) Detektering og behandling av kollisjonar. For kvart klokketikk har vi gjerne 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 ein ofte ikkje simulera 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. Så vil vi eventuelt også redusera farten for å ta med 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. Satelitten har jo styrta!

5) Plott alle objekt. Det siste vi normalt vil gjera når koordinatane til alle objekt er rekna ut, er å plotta disse objekta. Alternativt vil vi ta vare på posisjon og / eller fart osv.