Prosjektoppgave i FYS-MEK/F 1110 våren 2005

Transkript

1 1 Prosjektoppgave i FYS-MEK/F 1110 våren 2005 Tema: Bevegelse til et legeme i 1/r 2 sentralfelt fra to kilder samtidig Versjon f Prosjektoppgaven legges ut mandag 2. mai kl 0800 og leveringsfrist er onsdag 4. mai kl Prosjektoppgaven leveres enten direkte til gruppelærer eller på ekspedisjonskontoret (egen hylle med spalt i et plexiglassdeksel til høyre like innenfor døra). Dersom noen ikke klarer å få levert besvarelsen i tide, må det gjøres en individuell avtale med kursansvarig eller gruppelærer før fristen utløper. MERK: Les hele oppgaveteksten før du begynner å arbeide konkret med deler av oppgaven. Generelt krav til innlevert oppgave og litt om vurderingen Ved alle pålagte innleveringer av oppgaver ved Fysisk institutt - enten det dreier seg om obligatoriske oppgaver, hjemmeeksamen eller annet - forventes det at arbeidet er et resultat av studentenes egen innsats. Å utgi andres arbeid for sitt eget er uetisk og kan medføre sterke reaksjoner fra instituttets side. Derfor gjelder følgende: Hvis du tar med tekst, programkode, illustrasjoner og annet som andre har laget, må du tydelig merke det og angi hvor det kommer fra. Det er greit å få hjelp eller diskutere med andre hvorledes en oppgave kan løses, men dette skal i så fall brukes som grunnlag for egen løsning og ikke kopieres uendret inn. Kursledelsen vil trekke eller velge ut noen studenter for muntlig eksamen hvor vi blant annet vil gå gjennom besvarelsene til hver enkelt og forsikre oss om at arbeidet er selvgjort. Det er altså fullt mulig å samarbeide om løsning av obliger og prosjektoppgave, og det er fullt mulig å spørre gruppelærere og kursansvarlig om hjelp uten at det går ut over vurderingen av sluttresultatet. Hovedhensikten med prosjektoppgaven er at dere skal bli flinkere til å håndtere numeriske metoder i fysikken, og at dere skal beherske litt mer av det å utforske et system ved hjelp av numeriske eksperimenter. Samarbeider dere med andre med dette som hensikt, kan det øke læringsutbyttet og gjøre dere bedre skikket for fremtidig studier og yrkesliv. Men prosjektoppgaven har også et element i seg at den vil kunne påvirke endelig karakter i kurset. Besvarelsene blir etter vurdering plassert i tre kategorier: Normale besvarelser, og særlig gode og særlig svake besvarelser. Studenter som etter ordinær skoleeksamen i juni havner på vippen mellom to boksatvkarakterer, vil kunne få justert karakteren opp dersom deres prosjektoppgave ble vurdert som sælig god, tilsvarende justert ned dersom prosjektoppgaven ble vurdert som særlig svak. For de øvrige vil prosjektoppgaven ikke påvirke endelig karakter. Som en meget kort oppsummering kan vi si at Fysisk institutt krever at alle leverer sin egen besvarelse (ingen identiske besvarelser), og at alle kan gjøre rede for samtlige detaljer i det arbeidet de selv leverer. Hvis du er i tvil om hva som er lovlig samarbeid, kan du kontakte gruppelærer eller kursansvarlig. Husk å skrive på tydelig navn og gruppe på forsiden av besvarelsen, og å skrive navnet ditt som en kommentarlinje i samtlige programlistinger som gjengis i besvarelsen.

2 Side 2 Innledning Denne oppgaven er en videreføring av oblig 1: Bevegelse i sentralfelt. Vi skal rett og slett se på Jordas bevegelse rundt Sola, men i tillegg beregne bevegelsen til satelitten Rosetta i gravitasjonsfeltet fra Sola og Jorda idet Rosetta gjennomførte sin første Earth Swing-by ( gravity assist ) i mars i år. Denne oppgaveteksten er bygget opp på følgende måte: Noen opplysninger om Rosetta-sattelitten og valg av system for oppgaven. Initialbetingelsene og hvordan vi har fått tak i dem. Initialbetingelsene. Litt om likningsettet som vi benytter i beregningene. Noen kommentarer angående programmeringen. Selve oppgavebeskrivelsen. Praktiske opplysninger angående gjennomføring og levering. Det siste punktet bør man kanskje lese aller først, siden det er essentielt at man kommer seg gjennom oppgaven i rett tid. Mye hjelp tilbys, men man må selv vite å benytte seg av hjelpen dersom man trenger den! Noen opplysninger om Rosetta-sattelitten og valg av system for oppgaven Rosetta er en forskningssatellitt som ble skutt ut 2. mars 2004 med en Ariane 5G bærerakett. Selve satellitten hadde en masse på 3000 kg (hvorav 1670 kg er brennstoff for senere banekorrigeringer o.l.) og den er vel 2 meter i utstrekning alle veier (unntatt solpanelene som er større). Satellitten har 11 vitenskapelige instrumenter om bord. Satellitten skal etter planen gå i en bane omkring kometen Churyumov-Gerasimenko fra 2014 av, og vil ha et landingsfartøy som kan lande på selve kometkjernen for å undersøke denne nærmere. Også norsk astrofysikkmiljø deltar i Rosettaprosjektet, slik at noen av dere som tar FYS-MEK-kurset i år kanskje kommer til å jobbe med data fra Rosettasatellitten i deres doktorgradsarbeider om noen år! Mer informasjon om satellitten kan finnes på websiden Rosetta/. Man kan også finne stoff om Rosetta under En grunn til at vi har valgt Rosetta som utgangspunkt for vår prosjektoppgave, er at Rosettasatelitten bruker gravity assist for å øke den mekaniske energien til proben for at turen ut til kometen ikke skal ta alt for lang tid. Dette er en teknikk som få forstår og som ikke er pensum i teoridelen av kurset vårt. Vi vil bruke gravity assist bare som et eksempel på hvordan vi med numeriske eksperimenter kan utforske fenomener rundt oss, og bli litt vant med en litt annerledes arbeidsform enn den som er vanlig i informatikkurs. Dessuten er dette et problem hvor nøyaktighet spiller en vesentlig rolle, slik at vi får jobbet litt med litt mer presise teknikker for oppintegrering av Newtons lover enn det vi tidligere har møtt i kurset vårt. Disse teknikkene kan igjen anvendes i et vell av beregninger, i helt andre settinger enn det denne prosjektoppgaven omhandler. Ved å gjennomføre prosjektoppgaven vil du derfor opparbeide en generell kompetanse som er helt uavhengig av systemet vi har valgt som utgangspunkt for beregningene. Med andre ord, det at kraften dette året er en gravitasjonskraft, er av underordnet betydning, men akkurat de få studentene som skal studere astronomi videre (spesielt celest mekanikk) vil forhåpentligvis få litt ekstra utbytte.

3 Side 3 Initialbetingelsene og hvordan vi har fått tak i dem NASA og Jet Propulsion Laboratry har et elegant system kalt Horizons hvor man kan sende inn en med i størrelsesorden 20 parametre, for beregning av posisjon og hastighet av planeter, måner og satellitter, enten i et heliosentrisk koordinatsystem eller som posisjon på himmelen sett fra et angitt sted f.eks. på jorda. Det tar bare noen sekunder fra du sender mailen med dataene til du får tilbake en mail med ferdig beregnede verdier! For de som ønsker å bruke dette systemet er en orientering gitt på Erfaringsmessig tar det litt tid å sette seg inn i hvordan parametrene må gis for at man skal få de resultatene man er ute etter. De som er interessert i tips i å komme i gang med å bruke dette systemet, kan ta kontakt med kursansvarlig. Gjennom horizons-systemet har jeg fått et sett initialbetingelser som dere skal bruke for beregningene deres i denne prosjektoppgaven. Det er posisjon og hastighet til Jorda og til Rosetta pr 1. desember 2004 kl 1700 norsk tid. De opprinnelige dataene jeg fikk var slik: Jorda (Egentlig: tyngdepunktet til Jord-Måne-systemet): x= e+07, y= e+08, z= e+03 vx= e+01, vy= e+01, vz= e-04 Rosetta: x= e+07, y= e+08, z= e+06 vx= e+01, vy= e+00, vz= e-02 Alle koordinatene er gitt i antall kilometer (km) og hastighetene er gitt i kilometer pr sekund (km/s). Data for posisjon og hastighet vi fikk fra Jet Propulsion Laboratory er gitt med 16 gjeldende siffers nøyaktighet. Det er overkill så lenge vi ikke kjenner helt nøyaktig til hvilke verdier de har brukt for gravitasjonskonstanten og solas masse. Vi kjenner faktisk ikke disse to størrelsene med større nøyaktighet enn at det tilsvarer fire gjeldende sifre! Dersom du også neglisjerer z-komponentene og bare beregner baner i to dimensjoner, blir det egentlig meningsløst i våre beregninger å angi initialbetingelsene med så stor nøyaktighet som det vi fikk fra JPL. På den annen side er det ingen skade å gi tallene fullt ut. Vi bruker derfor dataene med fullt antall sifre, men må da huske at reell usikkerhet i våre beregninger er langt større enn antall sifre i initialbetingelsene tilsier. Vi merker oss at z-komponenten av Jordas posisjon (og hastighet) er svært liten sammenliknet med verdiene i xy-planet, og i denne prosjektoppgaven kan du neglisjere helt z-komponentene om du vil. For Rosetta-satellitten ser vi at det samme ikke er like fremtredende for den, siden z-komponenten av posisjonsvektoren er hele 7 % av komponenten i xy-planet. Du kan likevel om du vil velge å neglisjere z-komponentene av posisjon og hastighet også for Rosetta-satellitten slik at beregningene blir rent to-dimensjonale. Det kreves imidlertid ikke mye ekstra arbeid om du velger å gjøre beregningene i tre dimensjoner, men lar plottene være i to dimensjoner.

4 Side 4 Referansesystemet som er brukt er heliosentrisk, det vil si at Sola ligger i origo. Systemet er videre ekliptisk, det vil si at xy-planet er gitt ved planet utspent av Jordas bane omkring Sola. Dette planet endrer seg imidlertid sakte, så man må definere et fast plan over en hel tidsperiode for å slippe å endre på referansesystem kontinuerlig. Dataene ovenfor er gitt i forhold til et referansesystem kalt Reference epoch J (det forrige referansesytemet som ble brukt var knyttet til 1950-koordinater). Akseretningene forøvrig i det ekliptiske, heliosentriske koordinatsystemet, er gitt ved: xy-planet er planet utspent av Jordas bane omkring Sola (ved en tid definert gjennom referanseperioden J2000.0). x-aksen er valgt til å ligge i den oppadstigende noden (skjæringslinjen) mellom planet som Jordas bane har omkring Sola, og Jordas ekvatorplan (ved tid definert gjennom J2000.0). z-aksen er valgt vinkelrett på xy-planet på den siden av planet som Jordas nordpol peker. Merk spesielt definisjonen av hvor x-aksen er plassert i xy-planet. Husk at jordaksen ligger litt på skrå i forhold til ekliptikken (det planet som Jorda beveger seg i rundt Sola). Tegner du inn to plan i det heliosentriske referansesystemet, ett plan der Jorda beveger seg, og ett plan parallellt med Jordas ekvatorplan, men som går gjennom Sola, vil de to planene skjære hverandre langs en linje som går gjennom sola. Det er denne skjæringslinjen som danner x-aksen i referansesystemet vårt. Andre verdier du kan ha bruk for er som følger: G = 6.672e-11 N m 2 /kg 2 Solas masse: 1.99e30 kg (eller bedre: 1.989e30 kg) Jordas masse: 5.979e24 kg (månens masse 7.354e22 kg ser vi rett og slett bort fra). Det er på kursets websider lagt ut en fil med initialbetingelsene gitt i SI-enheter (m og m/s) for at du skal kunne klippe og lime til eget program og dermed unngå feiltasting ved innskriving. Litt om likningsettet som vi benytter i beregningene Vi skal akkurat som i oblig 1 se på bevegelse i sentralfelt, og likningsettet ser i prinsippet ut akkurat som den gang. Vi må imidlertid nå få inn virkelige fysiske størrelser i beregningene i stedet for den nokså intetsigende konstanten k vi brukte i oblig 1. I oblig 1 skrev vi at akselerasjonen (sum av alle krefter dividert på massen) var k k a = hvor k var en konstant. Akselerasjonen pekte alltid innover mot origo. Vi x 2 y 2 = r 2 viste da at dersom partikkelen har en posisjon (x,y), vil: kx ky = ---- og a y = ---- a x r 3 r 3 I vår prosjektoppgave er seltralfeltet gravitasjonskraften fra Sola når vi skal beregne Jordens bevegelse, og vektorsummen av gravitasjonskraften fra Sola og gravitasjoskraften fra Jorda når vi skal beregne Rosettas bevegelse. For det første, enkle tilfellet kan vi da skrive:

5 Side 5 a = GM r r 3 Vi har her antatt at vi bare behøver å ta hensyn til gravitasjonen fra Sola alene, og vi antar at Sola ligger helt i ro i origo. Radiusvektor peker fra origo til Jorda. For en to-dimensjonal bevegelse har både posisjonsvektor og akselerasjonsvektor to komponenter (i x- og y-retning). For bevegelser i tre dimensjoner er posisjons- og akselerasjonsvektorene redimensjonale. For Rosetta-satellitten derimot, vil vi måtte bruke både gravitasjonskraften fra Sola og gravitasjonskraften fra Jorda for å regne på bevegelsen i det intervallet vi har valgt ut, siden satellitten i denne perioden er nokså nær Jorda. Uttrykket for kraften som bestemmer bevegelsen til Rosetta-satellitten må derfor inneholde et ledd hvor posisjonsvektor for Rosettasatelitten relativt til Sola inngår, og et annet ledd hvor posisjonsvektor til satellitten relativt til Jorda inngår. Dette tilsvarer selvfølgelig en summasjon av krefter med ulik størrelse og retning. Den totale akselerasjonen til satellitten er ifølge Newons annen lov lik denne summen av krefter dividert på satallittens masse, akselerasjonen er selvfølgelig gitt i forhold til basis-referansesystemet vi arbeider i. Du skal selv sette opp likningsystemet vi da får (se konkrete oppgaver nedenfor). Noen kommentarer angående programmeringen. Vi har hittil i kurset brukt den enkle Eulers metode for å integrere opp Newtons andre lov for å beregne banen til partikler når kraften og initialbetingelsene er kjent. Eulers metode er svært enkel, men den har det problemet at vi bruker hastighet og akselerasjon i begynnelsen av hvert intervall når vi skal beregne hvordan henholdsvis posisjon og hastighet endrer seg i hvert intervall. Denne ensidigheten fører ofte til relativt store feil. Det finnes metoder som baserer seg på flere prøver på hvordan ting utvikler seg, og at man beregner neste punkt i tidsutviklingen ved hjelp at en smartere rutine. Vanlig er f.eks. å bare gå halve tidssteget og se på vinkelkoeffisienten der for så å bruke denne verdien (i stedet for vinkelkoeffisienten i starten av intervallet) for å beregne neste punkt. En videreføring av en slik tankegang ligger bak den mest populære algoritmen på dette området, nemlig den såkalte fjerde ordens Runge-Kutta metode. Her brukes Taylorutvikling til fjerde orden som basis for metoden, men vi skal ikke gå i detaljer om dette i vårt kurs. Vi vil likevel bruke denne metoden i vår prosjektoppgave for å få en bedre nøyaktighet enn vi kan oppnå med Eulers metode alene. De som er interessert i den bakenforliggende teorien finner den godt beskrevet på side i Tom Lindstrøms bok: Kalkulus, bind 1, Universitetsforlaget, Fjerde ordens Runge-Kutta ligger faktisk som en ferdig funksjon i Matlab, men vi skal bruke en åpen versjon for at du skal ha full oversikt over hva som skjer. Det kompliserer utregningene en smule, men ikke mye. Selv en 4. ordens Runge-Kutta kan få problemer i vår sammenheng dersom vi bruker faste tidssteg. Rosettasatellitten passerer nemlig Jorda såpass raskt at tidssteget må være svært kort for at beregningene av hva som skjer når Rosetta er nærmest Jorda skal bli tilstrekkelig bra. Men skal vi ha så fine tidssteg også for resten av beregningene, får vi en økende feil i områdene lengre fra Jorda fordi det da blir så fryktelig mange beregninger totalt.

6 Side 6 Veien ut av dette problemet er å bruke en såkalt adaptiv prosedyre der man justerer tidsstegene underveis slik at feilen som gjøres i hvert steg kommer under en fastsatt grense. Da kan tidsstegene være små der de fysiske kreftene endrer seg raskt med tiden (etter som satellitten fyker forbi Jorda), og langt større der kreftene varierer saktere. Dette er et elegant opplegg i og for seg, men man må da selv lagre tidspunktet for slutten av hvert tidsintervall for senere plotting o.l. Videre blir da den totale tiden etter N antall step sterkt avhengig av hvor fine tidsintervaller som faktisk ble brukt i den adaptive prosedyren, noe vi ikke har full kontroll over. Vi må derfor variere totalt antall step til vi har fått dekket et tilstrekkelig totalt tidsintervall. Dette kan gjøres manuelt eller ved å sette inn en eller annen test som avslutter beregningene når man har fått gjort det man spesielt er interessert i. Når vi bruker Runge-Kutta metoden eller adaptiv Runge-Kutta, er det to forhold som er vesentlig annerledes enn ved oblig1. For det første må du ha flere programmer å holde rede på samtidig og som må være lagret samme sted i datamaskinen: Ett program er hovedprogrammet ditt hvor du gir input-parametre, allokerer plass for arrayer og styrer beregningene og plotter resultater. Et annet program (funksjon) må inneholde koden som gir kraften (akselerasjonen) for det legemet vi gjør beregninger på. Vi må overføre nødvendige data gjennom parametre når denne funksjonen blir kalt, og returverdiene er rett og slett den deriverte til hver av parametrene vi skal finne tidsutviklingen til. Et tredje program (funksjon) er selve Runge-Kutta-funksjonen. Denne siste funksjonen får du oppgitt og du kan legge den inn på ditt område og du behøver ikke gjøre endringer på denne. Ved adaptiv Runge-Kutta får vi inn også et fjerde program (funksjon) som styrer hvor langt hvert enkelt tidssteg må være for at feilen i beregningene ikke skal bli for høy. Også denne funksjonen får du oppgitt og du behøver ikke gjøre endringer på den. En ekstra inputparameter er her feiltoleransen vi vil anvende. Ved ikke-adaptiv metode vil vi i vårt hovedprogram kalle RK-funksjonen, og i dette kallet overføre navnet på funskjonen vi har laget som beregner kraften (akselerasjonen) for systemet vi betrakter. RK-funksjonen vil så automatisk selv kalle vår funksjon for akselerasjonsberegning m.m. Ved adaptiv metode er det nesten som ved ikke-aktiv metode. Vi kaller nå den adaptive funksjonen fra vårt hovedprogram, og overfører filnavn til vår akselerasjonsberegningsprogram. Den adaptive rutinen vil så i sin tur igjen kalle den sentrale RK-funksjonen (flere ganger). Det er lagt ved et eksempelprogram for hvordan hovedprogram og hjelpeprogram kan se ut i en litt annen sammenheng enn vår. Det andre forholdet som er forskjellig nå sammenliknet med oblig1 er at vi vil nå utnytte Matlab bedre enn tidligere for å få mer kompakt kode. Vi har tidligere operert med x og y-komponenter hver for seg, og tilsvarende for hastighet og akselerasjon. Dette kan gjøres mer elegant ved å i stedet operere med vektorer, f.eks. r som har komponentene x og y (evt også z). I så fall vil r(1) = x, r(2) = y osv. På denne måten kan vi få en nettere skrivemåte for mange uttrykk. F.eks. vil vi i stedet for slik vi skrev for akselerasjonen i oblig1:

7 Side 7 a x kx ky = ---- og a y = ---- r 3 (hvor vi forresten også beregnet r separat vha Pythagoras) nå kunne skrive Matlabkoden så enkelt som: a = -k*r/norm(r)^3; Da er både x og y-komponentene (evt også z-komponenten) tatt hånd om samtidig, og beregningen av lengden av radius vektor er gjort vha norm-funksjonen. Her er det forutsatt at r er definert som en vektor før koden ovenfor brukes (størrelser på høyre side av likehetstegnet må jo alltid være definert før koden brukes). I så fall vil a bli en vektor, selv om den ikke var definert på forhånd. Dersom vi skulle ønske å finne ax alene, benytter vi at a(1) nettopp er lik ax. Men vi går faktisk lenger enn det! Vi kan i Matlab lage oss vektorer med hvilke som helst elementer satt sammen, bare vi selv holder orden på at de blir brukt på vettugt vis senere. Vi skal i denne prosjektoppgaven anvende en status-vektor som i første omgang har fire komponenter dersom vi arbeider i to dimensjoner, nemlig x, y, vx og vy, for å overføre fire tall samtidig fra et program til et annet, og også for å gjennomføre fire samtidige beregninger. Initialbetingelsene for hvert trinn i beregningen overføres slik i form av bare én vektor. Når du skal operere med Rosetta-satellittens bevegelse i et kombinert sentralfelt (både fra Sola og Jorda), må du til og med bruke en åtte-dimensjonell status vektor, med x, y, vx og vy for Jordas bane omkring Sola først, og x, y, vx og vy for Rosetta deretter. Arbeider du i tre dimensjoner, blir statusvektoren til og med tolvdimensjonal. Dette er nødvendig for å danne et riktig uttrykk for kraften som virker på Rosetta og på Jorda samtidig. Dette er elegant programmeringsmessig siden vi da får gjort masse beregninger for hver linje kode i dataprogrammet, men ulempen er at du må holde orden på komponentene selv og trekke ut de enkelte komponentene når du har bruk for dem enkeltvis. Se eksempelprogram tilgjengelig på kursets websider for detaljer. r 3 Ellers en litt mer generell betraktning: Vi bruker datamaskinen i vårt kurs som et hjelpemiddel for å gjøre eksperimenter i fysikk. Vi lager ikke programmer som skal være så brukervennlige som mulig med grundig dokumentasjon av alle ledd i programmeringen. Videre arbeider vi mer eller mindre interaktivt ved at vi kan endre på programmet, kjøre det, endre litt til, kjøre det på ny osv uten nevneverdig ventetid for hver kjøring. Det betyr at man kan arbeide på en annen måte enn ved f.eks. obliger i rene programmeringskurs. Det er ikke selve programmet som er målet i vår sammenheng, men informasjon om et system. Programmet er bare et hjelpemiddel. Det betyr at man behøver ikke lage ett og samme program som skal kunne utføre alle beregningene som prosjektoppgaven omhandler i en og samme kjøring. Vi behøver heller ikke å lage separate program for hver gang vi skal beregne en ny størrelse. I stedet kan vi beholde kode som ikke brukes, men bare kommentere denne bort eller inn (vha innsetting eller fjerning av % tegn i starten av linjen) alt etter hvilke oppgaver vi skal ha gjort. Forutsetningen er at du da gir noen kommentarer i koden som gjør det mulig å huske hvordan du modifiser programmet (noen linjer kommenteres ut, andre inn) for ulike kjøringer. Hver gang det gjøres store endringer i hvilke størrelser som skal beregnes, kan det likevel lønne seg å lage en litt ny vri av programmet for at det ikke skal bli alt for uoversiktlig.

8 Side 8 HUSK Å TA BACKUP OG ENDRE FILNAVN JEVNLIG SLIK AT DU IKKE MISTER FOR MYE ARBEIDSTID I TILFELLE DATAMASKINEN HENGER ELLER GÅR NED!!! Vi ber om at du legger ved en kopi av programmeringskoden for en bestemt beregning. Det er ikke nødvendig å legge ved koden for alle andre varianter av kjøringer, men det kan likevel være lurt å gi noen få linjer av programkoden som er spesifikke for de enkelte kjøringene. Husk at rapporten du skriver bør være tilstrekkelig detaljert til at du f.eks. om ti år skal kunne gå inn i besvarelsen og kunne repetere det du gjorde uten å gruble alt for mye på hvordan du egentlig kom fram til de resultatene du kom fram til. Husk å allokere plass til alle arrayer (tallrekker) før du går inn i løkken, ellers vil beregningene lett ta uforholdsmessig mye tid! Allokering kan f.eks. skje ved kode av typen xj = zeros(n,2); (for to-dimensjonale beregninger) for hver av tallrekkene du vil ta vare på under beregningene. Selve oppgavebeskrivelsen I første delen av oppgaven skal vi bare sjekke at våre beregninger fungerer rimelig bra for Jord-Sol-systemet alene. Vi neglisjerer at Jorda har en måne rundt seg som gjør at Jorda alene ikke har en ren elliptisk bane rundt Sola. Dette gjør vi ved at vi bare gjør beregninger på hvordan tyngdepunktet til Jord-Måne-systemet beveger seg omkring Sola. (Tyngdepunktet ligger jo allikevel innenfor Jorda, ca 3/4 vei fra Jordas sentrum til overflaten av Jorda.) a) Beregn og plot Jordas bane rundt Sola fra 1. desember 2004 og ett siderisk år framover ( døgn). Bruk en 4. ordens Runge-Kutta algoritme (ikke-adaptiv), og stykk opp banen i 1000 deler ved beregningene. (Ved de første uttestingene av programmet holder det godt med litt mindre antall punkter). Kontroller at Jorda etter et siderisk år er nokså nøyaktig tilbake til samme utgangspunkt som der den var da beregningene startet. Si litt om hvor godt du oppnådde dette. (Plottet behøver ikke skrives ut.) b) Varier antall steg i programmet ovenfor, men behold samme totale tid, og bedøm hvorvidt resultatet er kritisk avhengig av antall steg. Det kan være aktuelt å sammenlikne kjøringer for f.eks. N = 500, 1000, 2000 og Det holder med en kvalitativ bedømming. c) Beregn tidspunktet der Jordas bane krysser x- og y-koordinataksene i løpet av banen rundt Sola. (Naturlig at du får ut tidspunktet som antall sekunder etter tiden beregningene startet, men la gjerne datamaskinen gjøre dette om til antall (desimale) dager etter startdato for beregningene, og bruk deretter en kalender for å manuelt finne ut hvilke datoer dette tilsvarer.) Sier disse resultatene deg noe? Forsøk å forklare. I resten av oppgaven får du to baner å holde orden på samtidig, den for Jorda og den for Rosetta-satellitten. Skriv bare ut de plottene du trenger for endelig dokumentasjon/rapport. d) Utvid dataprogrammet slik at du beregner og plotter både Jordas og Rosetta-satellittens bane i perioden 1. desember 2004 til 1. juli Bruk fortsatt ikke-adaptiv metode. Del den gitte perioden i 1000 like deler (noe mindre ved uttesting). (Husk at du må endre både hovedprogram og det lille hjelpeprogrammet som gir uttrykk for den totale kraften som nå virker. Satusvektoren bør nå bestå av åtte elementer (evt 12), posisjon og hastighet både for Jorda og Rosetta.)

9 Side 9 e) Varier antall steg i programmet ovenfor, men behold samme totale tid, og bedøm hvorvidt resultatet er kritisk avhengig av antall steg. Det kan være aktuelt å sammenlikne kjøringer for f.eks. N = 500, 1000, 2000 og Det holder med en kvalitativ bedømming. Er det forskjell i forhold til resultatet i punkt b)? f) Beregn og plot avstanden mellom Jorda og Rosetta i den gitte perioden (avstand vs tid). Få også programmet til å skrive ut minste avstand på skjermen. (Husk: Jordradien er 6380 km, og at atmosfæren strekker seg vel 100 km over bakken.) Ser du noe interessant i plottet (bruk gjerne punktplotting i stedet for linjeplot, vha.r -parameteren i slutten av plotkallet)? Det kan være nødvendig å bruke zoom-funksjonen innen plottevinduet for å få fram nødvendige detaljer. g) Endre hovedprogrammet (og lagre på nytt navn!) slik at du nå bruker en adaptiv Runge- Kutta metode på samme problem som ovenfor. Bruk 1.0e-11 som feilmargin ved kall til rk4a, og juster ved prøving og feiling (eller på mer elegant vis) antall step (N) til at Jorda gjennomløper vel en halv runde rundt sola innenfor de beregningene du gjør. Gjenta samme beregninger som i punkt f), og se hvilke endringer du har nå sammenliknet med ikke-adaptiv kjøring. Er resultatet kritisk avhengig av angitt feilmargin? h) Beregn og plot den relative farten (tallverdien av relativ hastighet) mellom Jorda og Rosetta i den gitte perioden. Kommenter igjen spesielle detaljer du evt kan se av plottet. (Hint: Sammenlikningsgrunnlaget kan være systemet vi betraktet i oblig 1.) i) Beregn og plot den totale mekaniske energien (total potensiell pluss kinetisk) til Rosettasatellitten i den gitte perioden. Beregn endring i total energi for Rosetta fra første til siste punkt i beregningene. j) Bruk resultatene fra kjøringene ovenfor til å forklare hva som menes med gravity assist. k) Legg til en liten tilleggshastighet til initialbetingelsene for Rosetta og for å utforske hvor viktig initialbetingelsene er for det endelige resultatet. Den lille tilleggshastigheten skal være rettet normalt på Rosettas initielle hastighet i xy-planet, og rettet utover eller innover (vekk fra eller mot sola i xy-planet). Forsøk ca 10 ulike tilleggshastigheter varierende fra +5e-4 til -5e-4 ganger initiell fart i xy-planet. Notér for hver kjøring minste avstand Rosetta - Jord, og endring i total energi, og legg merke til kvalitativt hvordan Rosettas bane endres fra kjøring til kjøring. l) (Vanskelig:) Klarer du ut fra kjøringene ovenfor (pluss evt tilleggspresentasjoner så som posisjon til Rosetta relativt til Jorda under bevegelsen) til å forklare hva som er det essentielle punktet mhp om gravity assist skal kunne gi økt energi eller redusert energi? m) (Vanskelig?:) Forsøk å estimere hvor mye årets lengde for Jorda endres fordi vi bruker litt av Jordas mekansike energi til å øke Rosettas totale mekaniske energi. Praktiske opplysninger angående gjennomføring og levering Prosjektoppgaven har en betydelig dybde i den forstand at det bare er de aller flinkeste (eller ingen?) som forventes å komme gjennom alle delspørsmålene med full uttelling. Vi vil tro at de

10 Side 10 fleste vil gi seg mellom punkt g) og j), men håper at de fleste faktisk kommer til j). Husk at rapporten du skal skrive må inneholde beskrivelser av hva du har gjort og hvilke resultater og vurderinger du har gjort deg underveis. Det er viktig at du klarer å kommunisere til leseren hva du har funnet ut om de metodene vi har brukt, og om gravity assist som fenomen. NB: Legg ved en utskrift både av hovedprogrammet og hjelpeporgrammet (funksjonen for beregning av akselerasjon m.m.) du bruker på det mest avanserte nivået du kommer i prosjektoppgaven. Husk at det skal stå navnet ditt og dato i selve programkodene. Innlevering av den samlede rapporten kan skje i form av en papirutgave eller elektronisk. Papirutgaven kan legges i FYS-MEK/F-hylla på ekspedisjonskontoret eller leveres direkte til den av lærerne som er på vakt (se listen nedenfor). En elektronisk besvarelse kan sendes gruppelæreren din direkte, evt. sendes til a.i.vistnes@fys.uio.no. Dersom elektronisk innlevering benyttes, MÅ det skje i form at EN fil som kan skrives ut i sin helhet. Vi godtar IKKE løsninger basert på en samlig av flere ulike filer (.m-filer, tekst-filer.fig-filer osv) selv om de er pakket sammen i en.zip-fil. Vi godtar bare filer i.pdf,.ps eller.doc-format. En eller begge kurs-pc-stuene 329 og 245 vil være åpne hele døgnet mellom mandag 2. mai kl 0800 og onsdag 4. mai kl I tillegg kan dere bruke de vanlige PCstuene (Fysikkbygget, Kjemibygget, Biologibygget og Vilhelm Bjerknes hus m.fl.). Om nettene blir det antakelig bare én kurs-pc-stue åpen. For å komme inn og ut av bygningen etter ordinær stengningstid, kan du ringe den læreren som har vakt, se vaktlisten nedenfor. Det er et begrenset antall Matlab-lisenser (samtidige brukere) ved UiO, slik at det kan oppstå perioder der du ikke får adgang til Matlab. I så fall er det ikke annet å gjøre enn å vente noen minutter og forsøke igjen. Alle oppfordres sterkt til å logge ut fra Matlab hver gang du skal ta en mer enn 5 minutters pause i den direkte programmeringen, f.eks. hver gang du skal lese litt teoristoff eller diskutere med medstudenter eller ta en matpause. Oppdager vi at noen forlater PCen innlogget i mer enn fem minutter og uten spesiell avtale, kommer vi til å logge dere ut uten å sjekke at alt er lagret på forhånd. Studenter som har egen studentcd-versjon av Matlab oppfordres til bare å bruke denne. De slipper ventetid. Merk også at det kan bli mye kø på printerne de siste timene før innlevering. Forsøk å skrive ut litt underveis slik at ikke alt må ut til slutt. Vaktliste (mobiltelefonnummer i parantes) Første kollonne gjelder rom 329, siste kollonne rom 245. Mandag : Katarina ( ) og Arnt Inge ( ) : Katarina ( ) og Sigve (for Børge som snart skal disputere!) : Sigve ( ) og Arnt Inge ( ) : Katarina ( ) og Sigve ( ) Tirsdag : Cecilie ( ) (bare en på vakt her) : Bengt ( ) og Arnt Inge ( ) : Cecilie ( ) og Arnt Inge ( ) : Eduard ( ) og Arnt Inge ( ) : Einar ( ) og Arnt Inge ( ) Onsdag : Arnt Inge ( ) (bare en på vakt her) : Bengt ( ) (bare en på vakt her)