== Hvis du har noen andre kommentarer skriv gjerne her. Vær gjerne spesifikk

Følte dette var en øvelse i programmering og ikke numerikk. Lærte nesten ikke noe nytt, bare knot med programmering. Burde fått litt mer info på starten.

Mangler forutsetninger til å diskutere meteorologi

Kult prosjekt, men litt dumt at vi måtte få utdelt såpass mye kode. Var litt vanskelig å forstå alt og da ble det vanskelig å bygge videre på det. Det var også veldig dumt at malen for rapporten kom så sent som den gjorde.

Spennende prosjekt, men er ein del svake punkt diverre. Eksempelkoden er for dårleg, då den ikkje introduserer oss for nok elementer som trengs for å besvare spesielt oppgave 3 godt nok. Man burde ha fått meir tips på korleis plottinga i oppgave 3 kan løysast, då dette er ting me ikkje er kjent med fra før. Sitter og igjen med følelsen av at det blei for mykje knoting, og for lite læringsutbytte med å innføre kartelementet. Jonas Ghini gjer ein kjempejobb med å svare på epost og hjelpe alle som treng det. Uten hjelp fra han og andre blir det umogleg å gjere oppgave 3, spesielt når eksempelkoden bruker nye ting utan å forklare nok kva det er og korleis det funka. Det blir også for mykje plotting, og lite interessant kode, med ikkje mindre enn 22(!) plott(inkludert subplot) som skal inn i rapporten. Syns samstundes at tidspunktet er for dumt, då prosjektet er så stort at man må sitte første helga i påskeferien og jobbe med prosjektet sjølv etter å ha lagt inn god innsats siden prosjektet kom ut. Etter min meining er det og for lite informasjon om korleis man kan forvente at havstrømmen oppfører seg, spesielt då det er eit gjennomgåande element å påpeike realismen av rørsla til partiklene. Det er og dumt at studassane viser seg svake i å forstå kor ein del av problema i prosjektet ligger, og korleis det kan løysast, med ein gang me går vekk fra dei enkle problema, noko som gjer at det ikkje er noke særleg hjelp der å få. I tillegg er det veldig forstyrrande med ulike tilbakemeldinger, alt etter kven man spør om hjelp. Dette gjer at øvingstimane blir veldig uattraktive og bortkasta tid, då ein epost til noken med god peiling (Jonas Ghini) er mykje meir effektivt enn å gå i timane.
Dette prosjektet ble veldig langt og i den siste oppgava var man ganske "fortapt" uten hjelp fra den som hadde lagt prosjektet med koden. Det burde legges ut bedre eksempelkode i fremtiden slik at studentenes resultat ikke avhenger av om de fikk hjelp med koden av prosjektansvarlig.
Kul oppgave, morsomt å regne på noe "ekte". Føltes relevant og nyttig også for senere. Et lite forbedringspotensiale: Det er ikke godt nok å komme med en rapportmal vel over en uke inn i prosjektet. Den bør være på plass fra prosjektstart. Det virket heller ikke som om det var helt klart for alle studassene hva som egentlig var forventet å være med i rapporten, noe som virker litt rotete og gir inntrykk av at det er litt svikt i kommunikasjonen mellom partene.

Bra med kodekurs med vitasser. Dette kunne det gjerne vært mer av og det kunne ha kommet før. Slryt til Jonas Ghini for å ta seg tid til å hjelpe utover timens avsatte tid. Mest lettfattede oppgaveteksten og rapportmalen sålangt.

Litt for lite fysikk synes jeg, til å være prosjektet fra tekfys. Her kunne man jo dratt inn masse kul kvante!

Veldig bra å kunne koble teori med noe mer fysisk! Igjen var programmeringen grunnen til at ting tok lang tid og ble knotete.

Var litt vanskelig å huske detaljene av prosjektet så lenge etterpå. Så tror det hadde vært en fordel om spørreundersølelsen kom litt kjappere etter prosjektet :)

Dette prosjektet tok nesten livet av meg. Lærinsutbyttet var minimalt på oppgave 2 og 3, da mesteparten av tiden ble brukt på å få vedlagt kode og pakker til å fungere. Synes prosjektet kunne gitt seg etter oppgave 2. Det var rett og slett alt for langt.

Spørreundersøkelsen kunne gjerne kommet rett etter innleveringsfristen. Da hadde det vært lettere å huske kommentarene vi hadde til prosjektet. Prosjektet var krevende, og det tok mye tid. Hvor mye hjelp vi fikk i øvingstimene varierte veldig med hvilken studass vi fikk hjelp av. Noen så knapt på koden vår, og sa at vi måtte debugge den (noe vi allerede hadde prøvd å gjøre i lang tid). Det mest nyttige var de studassene som faktisk så på koden, og prøvde å finne feilen selv.


== Hvis du har noen kommentarer i forbindelsen med faget, som øvinger, forelesninger og lignende, skriv gjerne her. Det settes stor pris på!

Hovedproblemet med dette faget er at brorparten av tiden blir brukt på å gjøre prosjekter, og så telles disse relativt like i forhold til eksamen. Det hadde egentlig ikke trengt å vært noe eksamen i dette faget i det hele tatt, da det gir lite mening å skrible ned numeriske metoder på papir. Mest effektiv tidsbruk i faget for å få god karakter ville vært å nedprioritere prosjektene kraftig og heller utnyttet tiden på å drive eksamensforberedelser.

Et annet problem er at det er stort fokus på å diskutere modellen i prosjektene (2&3). Dette er forutsetninger vi ikke har, da mye av den fysiske teorien som blir presentert i prosjektene(2&3) er ukjent. Vi har ingen forutsetninger for å diskutere gyldigheten i kabelmodellen i prosjekt 2 og vi har ingen forutsetninger på å diskutere gyldigheten til partikler i havet i prosjekt 3. Faget burde heller fokusert på å rendyrke numerikken, så får heller fysikken læres i senere årskurs.

Programmeringsoppgavene i øvingsopplegget oppleves dessuten overflødig da dette ikke er eksamensrelevant.

Prosjektene generelt har lite å gjøre me pensum. Synes faget enten kunne bestått av kun øvinger og forelesninger som svarte til øvingene, eller ikke hatt så store og tidkrevende prosjekter. Studassene må få klar beskjed om hva som kreves av studentene i forhold til prosjektene, og hva rapporten må inneholde. Prosjektene må klargjøres tidligere slik at studassene får tid til å sette seg inn i hvordan man løser problemene og det må være bedre dialog mellom studasser og de som retter øvingene som nevnt tidligere.

Forelesningene har vært litt rotete og vanskelig å henge med på. Det ble ofte mye teori og beviser. Det var lite visuelt og lite eksempler.

Forelesning: fortsett på engelsk, og bli endå flinkare til å påpeike kor i boka man er, og kva det er man faktisk lærer om. Bli gjerne meir konsekvent på notasjon då det er forvirrende å lese tilbake og man bytter på å markere kva steg man er på i ein Runge-Kutta f.eks med å ha tall enten oppe eller nede.

Øvinger: Litt fleire spennande oppgåver? Lag gjerne fleire oppgåver sjølv, då noken av oppgåvene frå boka er frykteleg repetetive/ mindre spennande, veldig på detaljnivå og rare, som man berre må lese rett av teoridelen.

Studentassistentane: Fått litt dårleg inntrykk av studassane, når dei på fleire av prosjekta virker å ikkje heilt forstå problem med ein gang man viker frå dei enkle problemstillinga, og ting som står i LF. Dette gjorde iallefall øvingstimane under prosjekta uaktuelle å gå i, då det var betre hjelp å få andre plassa. I kvart prosjekt MÅ det vere klare retningslinjer for korleis dei ynskjer ting, då det varierer heilt fra person til person.
Spesielt å få trekk i prosjekt 1 for å gjere ting som studass sa eksplisitt at dei ville ha, det er utruleg demotiverande.

Generelt: Begynn faget med kodekurs, som det Jonas hadde under prosjekt 3. ITGK er ikkje godt nok grunnlag for god kodeskikk, plotting og optimalisering av kode. Introduser alle for pycharm, da denne funker mykje betre enn blant anna pyzo som mange kjenner frå fysikkfaga. Ellers stor applaus til Jonas B Ghini som har trått til og redda prosjekt 2 og 3.
Angående prosjektoppgavene: Jeg synes det er merkelig at det ikke er samme person som retter øvingene. Slik jeg (nå) forstår det rettes øving 1 av en person, mens de to andre rettes av en andre person. Da virker øving 1 mot sin hensikt(slik jeg forstår det): Den skal være en slags "oppvarming" til, og rettesnor for, de senere øvingene og dermed kun telle symbolske 4%. Jeg opplevde det som at den ble rettet mot en helt annen standard enn øving 2, og helt ulike ting ble vektlagt (bl.a. viktigheten av fysiske forklaringer, ryddig kode, osv.). Tilbakemeldingen på øving 1 viste seg å bli ubrukelig, og en bra score på denne var heller villedende enn veiledende. Dermed virker det i ettertid rart at den ikke skal telle like mye som de to andre, spesielt da den var vel så mye arbeid. Videre fortoner prosjektoppgavene seg som en konkurranse i å huke tak i "riktig" studass, og mye tid gikk med til nærmest å "faktasjekke" det de andre studassene sa.


Om faglærer kunne, kanskje i samarbeid med studenter, skrevet et kompendium, hadde det vært gull verdt. Spesielt når det ikke finnes videoforelesninger.

Artig fag!

Jeg tror jeg hadde fått mer læringsutbytte av prosjektene om vi hadde hatt lenger tid på å gjennomføre dem, og heller hatt to prosjekter istedenfor tre. Da hadde arbeidsmengden samsvart mer med tiden vi hadde til rådighet. I tillegg overvurdere dere programmeringsferdighetene våre, noe som gjorde at prosjektene ble veldig tidkrevende og vanskelige. Python-tutorialen i forbindelse med siste prosjekt var et godt initiativ, men det var ikke så veldig hjelpsomt. Det gikk for fort for å få med seg all koden som ble skrevet, og han ville heller ikke legge ut det han hadde skrevet i ettertid. Da ble det ganske halvveis.
Det hadde vært fint om det ble lagt ut et skjema før rapportene skulle bli skrevet om hva man blir vurdert i, og hvor viktig de forskjellige deloppgavene var. I vurderingen av prosjekt 1 ble det ikke tatt hensyn til programkode (i hvert fall ingen tilbakemelding), men dette ble vurdert i prosjekt 2, dette burde blitt kunngjort før levering. Det hadde også vært fint å vite poengfordelingen over forskjellige deloppgaver i prosjekt 2, slik at man visste hva man burde fokusert på; noen grupper kan ha brent seg på å ha fokusert mer på deloppgaver med færre poeng. Prosjektene har (allikevel) vært både kjekke, nyttige, utfordrende og gitt en god smak på bruk anvendt matematikk.