Spektriä pukkaa¶
Elektronispektroskopiassa materiaa tutkitaan säteilyttämällä sitä kirkkaalla valolla ja mittaamalla siitä irronneiden elektronien kineettistä energiaa. Kun valon fotonien energia tiedetään, voidaan sitä ja elektronien kineettistä energiaa käyttämällä laskea elektronin irroittamiseen vaadittu työ. Tämä antaa tärkeää informaatiota aineen elektronirakenteesta ja siten sen kemiallisista ja fysikaalisista ominaisuuksista. Tapahtumaa, jossa fotoni irroittaa atomista elektronin kutsutaan fotoionisaatioksi ja irronneita elektroneja fotoelektroneiksi.
Tässä harjoitustyössä tehtävänäsi on analysoida argonin fotoionisaatiospektriä. Tehtävänanto sisältää (simuloitua) dataa mittauksesta, jossa argon-atomeita on ionistu säteilyllä ja irronneiden elektronien kineettinen energia on mitattu. Tehtävässä pääset kirjoittamaan ohjelman, joka osaa ladata datan tiedostoista, piirtää sen näkyviin, muokata sitä ja laskea siitä erinäisiä kiinnostavia arvoja. Lisäksi opit käyttämään ulkoisia kirjastoja (numpy, matplotlib).
Ohjelmistoista¶
Tässä työssä tarvitaan kahta kolmannen osapuolen kirjastoa: numpy ja matplotlib. Näille löytyy useita asennustapoja. Windows-asennusohjelmat löytyvät internetistä, ja asennus onnistuu myös pip install -komennolla. Internetistä löytyy myös ns. full stack -paketteja, joissa tulee mukana Python ja tarvittavat kirjastot - nämä tyypillisesti asentuvat oman Pythonisi päälle. Mikäli käytät jotain full stack -pakettia, mainitse asiasta ohjelmasi alussa kommenttirivillä, koska ne saattavat käyttää eri versioita kirjastoista kuin erikseen asennetut. Kirjastot on myös asennettu PC-luokkien virtuaalikoneisiin.
Lisäksi tarvitset pienen kirjaston graafista käyttöliittymää varten - siitä lisää alempana.
Tarkemmat vaatimukset¶
Argonin spektrin mittaus on suoritettu useamman kerran ja jokainen mittauskerta löytyy omasta tiedostostaan ("measurement_x.txt", missä "x" on kyseisen mittauskerran järjestysnumero). Tiedostoissa on jokaisella rivillä kaksi liukulukua. Ensimmäinen kertoo mitatun energian perusteella lasketun sidosenergian (yksikkönä elektronivoltti). Toinen luku on kyseistä energiaa vastaava intensiteetti (mielivaltainen yksikkö, mutta kertoo suurinpiirtein paljonko kyseisen energian elektroneja on mitattu). Jokaisessa mittauksessa sidosenergiat ovat samat tasaväliset luvut. Ohjelmasi tarkoitus on summata jokainen mittauksista yhteen. Tällöin yksittäisessä mittauksessa oleva satunnainen heilahtelu toivonmukaan kumoutuu ja ainoastaan kokeellisesti mielenkiintoinen signaali jää jäljelle.
Spektriin tulee mittauslaitteistosta johtuva lineaarinen tausta, eli spektri näyttää piikkejä lukuunottamatta laskevalta suoralta. Tämä taustasignaali pitää poistaa spektristä ennen sen analysointia. Poistaminen tapahtuu valitsemalla spektristä kaksi pistettä (alku- ja loppupäästä) ja sovittamalla näihin pisteisiin suora. Sen jälkeen spektrin jokaisesta pisteestä vähennetään samaa energiaa vastaava suoran arvo.
Tätä spektriä tutkittaessa olemme kiinnostuneet kahden spektrissä näkyvän piikin intensiteettien suhteesta. Piikkien intensiteetit saadaan laskemalla niiden pinta-ala integroimalla. Integroinnissa käytetään puolisuunnikassääntöä. Teorian mukaan energiassa ensimmäisen piikin intensiteetin tulisi olla noin kaksi kertaa suurempi kuin toisen piikin.
Ohjelmassasi pitää olla seuraavat ominaisuudet:
- Ohjelmassa on graafinen käyttöliittymä, josta käyttäjä voi valita ohjelman eri toiminnot.
- Ensimmäinen toiminto lataa datan tiedostoista ohjelman muistiin. Aliohjelma etsii käyttäjän valitsemasta kansiosta tiedostoja, joiden nimi on ylläolevaa muotoa ja lukee niissä olevan datan. Aliohjelman tulee luoda ohjelmaan muistiin kaksi taulukkoa, joista toisessa on mitatut kineettiset energiat ja toisessa summa jokaisesta mitatusta intensiteetispektristä. (Eli jokaista yksittäistä energiaa vastaavat intensiteetit eri mittauksista on laskettu yhteen.) Lopuksi aliohjelma ilmoittaa käyttäjälle montako tiedostoa ladattiin.
- Toinen toiminto piirtää sen hetkisen ohjelman muistissa löytyvän datan näkyviin. Mikäli mitään dataa ei ole ladattu, tästä ilmoitetaan käyttäjälle jollain tavalla. Data piirretään näkyviin käyttämällä matplotlib-kirjastoa, ja käyttöliittymään upotettua kuvaajaa sekä piirtoaluetta. Kuvaajan pitäisi näyttää suurin piirtein alla olevan esimerkin mukaiselta.
- Kolmas toiminto poistaa spektristä lineaarisen taustan. Mikäli mitään dataa ei ole ladattu ohjelman muistiin, ilmoitetaan tästä käyttäjälle. Käyttä valitsee kaksi pistettä klikkaamalla niitä kuvaajasta, ja ohjelma sovittaa näihin pisteisiin suoran sekä vähentää ohjelman muistissa olevasta spektristä taustan.
- Neljäs toiminto laskee spektristä löytyvien piikkien intensiteetit. Mikäli mitään dataa ei ole ladattu ohjelman muistiin, ilmoitetaan tästä käyttäjälle. Integrointi tehdään käyttämällä puolisuunnikassääntöä, josta löytyy toteutus numpy-kirjastosta (numpy.trapz). Käyttäjä valitsee energiavälin klikkaamalla kuvaajasta. Tämän jälkeen ohjelma laskee piikin pinta-alan ja ilmoittaa sen käyttäjälle.
- Viides toiminto antaa käyttäjän tallentaa kuvaajan ohjelman muistissa sillä hetkellä olevasta datasta. Mikäli mitään dataa ei ole ladattu ohjelman muistiin, ilmoitetaan tästä käyttäjälle. Aliohjelma kysyy käyttäjältä tiedostonnimen, jolla tämä haluaa kuvaajan tallentaa. Sen jälkeen aliohjelma tallentaa käyttäjän antamalla nimellä samanlaisen kuvaajan kuin mitä toisessa aliohjelmassa piirretään näkyviin. Kuvaajien tallentamiseen löytyy omat metodinsa matplotlib-kirjastosta. Kuvaajat voi tallentaa .png-muodossa.
Kuvaajia piirtäessä muista antaa akseleille mielekkäät nimet (kuten esimerkkikuvassa). Tähän löytyy matplotlibistä omat komennot.
Grafiikka¶
Käyttöönotto¶
Kirjasto rakentuu Pythonin normaaliasennuksessa mukana tulevan TkInter-kirjaston päälle, ja tarjoaa siitä rajusti yksinkertaistetun rajapinnan funktioiden kautta. Kirjaston dokumentaatiomerkkijonot kertovat miten sitä käytetään. Kirjaston pääohjelmassa on myös lyhyt esimerkki siitä, miten sillä tehdään yksinkertainen käyttöliittymä.
Käyttöliittymäkirjastojen 101¶
Käyttöliittymäohjelmoinnissa kirjastoissa on tyypillisesti pääohjelmasilmukka, joka pyörii ns. konepellin alla. Kaikki mitä käyttäjä tekee käyttöliittymässä kytketään yleensä käsittelijäfunktioihin. Kun käyttäjä vaikkapa painaa nappia, kutsutaan nappiin kiinnitettyä käsittelijäfunktiota, joka tekee Jotain (tm). Ohjelma ei siis etene samalla tavalla lineaarisesti kuin tähän asti on totuttu. Käyttöliittymät muodostuvat elementeistä joita kutsutaan widgeteiksi. Nämä voivat olla yksinkertaisia, kuten painonapit, tai monimutkaisempia kuten vaikkapa kokonainen tiedostonavausikkuna, joita näkee useimmissa ohjelmissa.
Tyypillisesti pääohjelmassa luodaan käyttöliittymän ulkoasu valitsemalla mitä elementtejä sinne laitetaan. Samalla määritellään elementtien ominaisuudet ja erityisesti niiden käsittelijäfunktiot. Loppu koodauksesta on näiden käsittelijäfunktioiden sekä erilaisten apufunktioiden tekemistä (joita käsittelijäfunktiot käyttävät).
Yksi erityispiirre on se, että koska funktioita kutsutaan ulkoisesti kirjaston toimesta, emme voi hallita sitä mitä tietoa niille annetaan. Ohjelman tilaa ei siis voi kuljettaa funktion argumenteissa, vaan se täytyy esittää jollain muulla tavalla. Hyvä vaihtoehto tämän lopputyön kontekstissa on tehdä sanakirja, johon talletetaan esim. ladattu data sekä pisteet, jotka käyttäjä on valinnut. Jos sanakirja on määritelty pääohjelmassa, sitä voidaan muuntuvuutensa ansiosta käsitellä kaikissa funktioissa. Tällöin mikä tahansa funktio voi lukea ja muuttaa ohjelman tilaa ilman, että sille tarvii antaa sitä argumenttina.
Yhteistyö¶
Me tykkäämme tällä kurssilla yhteistyöstä. Näitä viikottaisia kivoja pikku tehtäväpakettejakin on värkkäilty monen assistentin voimavaroilla. Yhdessä näitä ongelmia on varmaan myös kivempi ratkoa. Kaverilla voi olla parempi käsitys jostain asiasta, ja muutenkin kaksi silmäparia on tehokkaampi virheitä etsiessä. Usein oman virheensä tajuaa jo siinä vaiheessa kun alkaa kaverille avautumaan siitä, että ohjelma ei toimi. Niinpä siis emme missään nimessä halua ryöstää teiltä tätä yhdessä tekemisen riemua ja kannustammekin kysymään assistenttien lisäksi apua myös kavereilta.
Tällä kurssilla on kuitenkin vaatimus, että jokainen opiskelija oppisi ohjelmoimaan ihan itse. Tämä on hyvä pitää mielessä kun värkkäilee koodia kaverin tai useamman kanssa. Mitään ei kannata naputella omaan koodiin ilman, että tajuaa, mitä siinä tapahtuu. Vaadi kavereiltasi selitystä, jos et ymmärrä saamaasi neuvoa! Koodin muilta kopioinnissa on semmoinen ikävä puoli, että kaikki häviävät. Se joka kopioi, ei itse viisastu kopioimastaan millään tavalla, ja se, jolta kopioidaan, ei pääse syventämään omaa ymmärrystään asiasta muotoilemalla sen ymmärrettävään muotoon.
Näitä tapauksia sattuu kuitenkin vuosittain, joten pelkkien kauniiden ajatusten lisäksi kurssilla on selkeät ja helposti ymmärrettävä pelisäännöt yhteistyötä koskien. Noudatahan näitä sääntöjä niin vältyt ongelmilta. Ongelmat yleensä tarkoittavat, että suoritusmerkintääsi saatetaan pantata jonnekin hamaan tulevaisuuteen kun asiaa selvitetään. Pahimmassa tapauksessa voi käydä niinkin ikävästi, että joudut uusimaan kurssin. Säännöt voi tiivistää muutamaan kohtaan:
- Älä kopioi koodia mistään tai keneltäkään ja pidä huoli siitä että ymmärrät aina kaiken koodin mitä kirjoitat
- Ilmoita aina kenen kanssa olet tehnyt yhteistyötä. Tiedostotehtävissä on tätä varten oma kenttänsä
- Jos otat mallia jostain muualta (Internet), merkitse kommenteilla koodin yläpuolelle mistä se on otettu
Lopputyötä voi tehdä yhdessä kaverin tai useamman kanssa. Tällöin on kuitenkin pidettävä huoli siitä, että kaikki tekijät ovat kartalla siitä, mitä ohjelmassa tapahtuu ja osallistuvat sen tekemiseen. Kannattaa huomioida, että lopputyön tarkastamisessa ja katselmoinnissa keskitytään siihen, miten hyvin sinä itse osaat ohjelmoida ja miten se tulee esiin. Maailman paraskaan koodi ei mene läpi, jos se on kokonaan jonkun muun tekemä.
Työn hyväksyminen¶
Hyväksyttävään työhön vaaditaan ohjelma, joka toteuttaa tällä sivulla esitetyt vaatimukset. Ellei koodisi ole aivan luokattoman huonoa, tyypillisesti kaikki täysin toimivat ohjelmat hyväksytään. Puutteiden paikkaamiseen on mahdollisuus kunhan työn ensimmäinen versio on palautettu ajoissa. Työn palautuksen lisäksi hyväksyttyyn suoritukseen kuuluu 15 minuutin keskustelu assistentin kanssa. Tähän keskusteluun kuuluu, että assistentti esittää kysymyksiä koodistasi. Mikäli et pysty vastaamaan kaikkiin kysymyksiin tyydyttävästi, saat kotitehtäväksi opetella koodisi toiminnan tarkemmin ja joudut varaamaan uuden keskusteluajan. Säännöt vaativat meitä varmistamaan, että opiskelijat ovat tehneet oman työnsä. Kyse on kuitenkin myös tärkeämmästä periaatteesta: ohjelmoijan ei tulisi koskaan lähettää eteenpäin koodia jota ei itse ymmärrä. Ohjelmoija on aina vastuussa omasta koodistaan.
Koodin laatu¶
Kurssilla on pyritty opettamaan tapoja tuottaa hyvää koodia, ja sen odotetaan näkyvän myös lopputyössä. Ihan mikä tahansa toimiva toteutus ei vielä takaa läpipääsyä, jos koodin laatu on aivan sekundaa - vastaavasti erittäin laadukkaalla toteutuksella voi paikata hieman vaillinaista toteutusta. Sinänsä tässä ei pitäisi tulla ongelmia, jos oppimateriaalit on käyty kunnolla läpi. Alla on hieman suuntaa antavia ohjeita miten eri laatukategorioita katsotaan. Tavoitteena olisi saada jokaiseen kohtaan vähintään "hyvä".
Muuttujat ja nimeäminen¶
- huono: Muuttujien ja funktioiden nimistä on mahdoton päätellä mihin ne on tarkoitettu tai mitä ne sisältävät.
- hyvä: Muuttujien ja funktioiden nimistä pystyy pääasiassa päättelemään mihin ne on tarkoitettu, vaikka osa nimistä voikin olla lähinnä "vähän sinne päin". Asioita on nimetty usealla eri kielellä ja nimeämiskäytäntö ei muutenkaan ole välttämättä kauhean yhdenmukainen.
- erinomainen: Ohjelmassa on johdonmukainen ja yhtenäinen nimeämiskäytäntö. Lisäksi muuttujien määrä on hillitty, ja ohjelmassa on vältetty turhia muuttujaansijoituksia. Vastaavasti ohjelmassa on käytetty muuttujaansijoitusta silloin, kun koodirivistä uhkaa muuten tulla liian pitkä.
Ehtolauseiden käyttö¶
- huono: Ehtolauseiden
elif
- jaelse
-osien käyttö puuttuu kokonaan tai on hyvin vajavaista. Vastaavastiand
- jaor
-operaattorit eivät ole hallussa. Näistä johtuen ehtolauseet näyttävät todella hankalilta. Ylipäätään ehtolauseet saattavat toimia enemmänkin vahingossa kuin tarkoituksella. - hyvä: Pääosin ehtolauseet ovat järkeviä. Tämä tarkoittaa sitä, että
elif
- jaelse
-osia on osattu käyttää, kuten myös sisäkkäisiä ehtolauseita sekä em. loogisia operaatioita. Ehtolauseet saattavat kuitenkin olla vähän huteran näköisiä ja tarpeettoman monihaaraisia. - erinomainen: Ehtolauseet ovat nättejä ja ytimekkäitä. Kaikkia em. keinoja on käytetty siten, että ne parantavat koodin luettavuutta ja mahdollistavat erilaisten tilanteiden tunnistamisen siten, että käyttäjällekin pystytään kertomaan, mitä pelissä tapahtuu.
Tietorakenteet (lue: listat, monikot, sanakirjat)¶
- huono: Tietorakenteita ei ole käytetty lainkaan, tai hyvin vähän. Tämä ilmenee koodissa siten, että siellä on paljon muuttujia, joiden nimessä on numero. Vähiä tietorakenteita on väärinkäytetty siinä määrin, että pahaa tekee.
- hyvä: Listoja ja kumppaneita on käytetty muodostamaan järkeviä tietorakenteita sellaisiin paikkoihin, joissa niitä selkeästi tarvitaan. Sellaisissa paikoissa, joissa tarve ei ole ilmeinen, on sen sijaan saatettu käyttää numeroituja muuttujia tai muita vastaavia keinoja.
- erinomainen: Tietorakenteita on käytetty ilmeisten paikkojen lisäksi silloin, kun niillä saa aikaan tiivimpää ja selkeämpää koodia. Myös sisäkkäiset tietorakenteet ovat selkeästi hallussa. Tietorakenteita on toteutuksen kannalta minimaalinen määrä.
Silmukoiden käyttö¶
- huono: Kaikki silmukat on tehty samaan muottiin, vaikka väkisin. Esimerkiksi kaikki silmukat on voitu tehdä
while True
-muottiin, vaikka siellä käytäisiin sisällä läpi listaa. - hyvä: Silmukoissa on osattu tunnistaa milloin tarvitaan
while
a ja milloinfor
ia. Silmukkamuuttujien käyttöfor
-lauseissa saattaa olla vähän hakusissa, ja silmukointi ei välttämättä ole optimaalista. - erinomainen: Silmukat ovat tehokkaita, ja niiden määrä sekä niissä pyörittyjen kierrosten määrä on pääasiassa juuri sen verran kuin on tarpeen eikä yhtään ylimääräistä. Silmukkamuuttujia käytetään hyvin – erityisesti sisäkkäisten listojen tapauksessa – ja temput kuten enumerate ovat hallussa, jos niitä tarvitaan.
Funktioiden käyttö¶
- huono: Ei lainkaan funktioita, tai funktioita on käytetty lähinnä funktioiden käyttämisen vuoksi. Funktiot eivät millään järkevällä tavalla jaa ohjelmaa toiminnallisiin kokonaisuuksiin. Argumenttien käyttöä on liberaalisti kierretty käyttämällä globaaleja muuttujia.
- hyvä: Funktiot jakavat ohjelman loogisiin kokonaisuuksiin, vaikka kokonaisuudet saattavat ollakin ajoittain turhan suuria. Argumenttien ja paluuarvojen käyttö on ymmärretty oikein. Mahdollinen globaalien muuttujien käyttö on rajallista ja perusteltavissa.
- erinomainen: Funktiot on jaettu siinä määrin hyvin, että ne kaikki ovat miellyttävän lyhyitä ja selkeästi rajattuja toiminnaltaan. Ainoastaan pääohjelma tai -funktio voi olla hieman lihavampi. Sekin on kuitenkin järjellisissä rajoissa. Argumenttien kuskaus funktiosta toiseen on tehty järkevästi siten, ettei kaikkea tarvitse raahata joka paikkaan. Jos globaaleja muuttujia on käytetty, niiden käyttö on perusteltu.
Moduulien käyttö¶
- huono: Moduuleja ei ole käytetty lainkaan, minkä takia ohjelma ei edes toimi toivotulla tavalla. Nollan pisteen arvoinen suoritus on myös käyttää pelkästään
from import
ia vaikkei siinä olisi mitään järkeä. - hyvä: Tarvittavat moduulit on löydetty ja niitä on osattu käyttää.
- erinomainen: Ohjelmassa on osattu käyttää moduulien hieman kehittyneempiä ominaisuuksia (esim. time-moduulin muotoilufunktiot) tai on käytetty jotain uutta moduulia lisäominaisuuden tekemiseen. Oma koodi on jaettu moduuleihin, jos se on tarpeen (tiiviin koodin tapauksessa yleensä ei ole!)
Virheenkäsittely¶
- huono: Ohjelmassa ei ole lainkaan virheenkäsittelyä, joten aina kun jotain menee pieleen käyttäjälle heitetään Pythonin virheilmoitusräjähdys. Ohjelma ei muutenkaan selviä virhetilanteista hajoamatta, mikä voi kaatumisen lisäksi ilmetä sellaiseen tilaan joutumisella, että siitä ei päästä pois.
- hyvä: Virheet on pääasiassa käsitelty joitain eksoottisia tapauksia lukuunottamatta. Käyttäjällä on jonkinlainen haju siitä miten tulee toimia, ettei ohjelma hajoile. Virheenkäsittelymenetelmät eivät aina ole sieltä optimaalisimmasta päästä.
- erinomainen: Virheenkäsittelymenetelmät on valittu järkevästi siten, että käyttäjälle saadaan aina mahdollisimman hyvää tietoa vikatilanteessa. Pääasiassa
try
-lohkot sisältävät hyvin minimaalisen määrän koodia. Ohjelma osaa käsitellä eksoottisetkin ongelmatapaukset.
Tiedostojen käyttö¶
- huono: Tiedostoja ei ole käytetty tai tiedostojen luku tehdään jollain hyvin kyseenalaisella tavalla (jota ei ole kurssilla edes opetettu). Vaihtoehtoisesti koodissa on pelkästään tiedostoihin kirjoittamista, eikä lainkaan lukemista.
- hyvä: Tiedostoja kirjoitetaan ja luetaan jollain tavalla siten, että tilastointivaatimus täyttyy. Vaihtoehtoisesti pelissä on jokin muu tapa käyttää tiedstoja, esim. tallentaminen ja lataaminen.
- erinomainen: Tiedostoja on käytetty älykkäästi siten, että kuka tahansa pystyy pelkästään tiedostoa katsomalla päättelemään, millainen lukija sitä varten pitäisi koodata.
Erikoismaininnat¶
Näitä voi pitää eräänlaisina ylimääräisinä saavutuksina:
- Luettavuus: Koodin luettavuus on erittäin hyvä. Tämä tarkoittaa sitä, että nimet, välilyönnit yms. ovat kurssin ohjeistuksen mukaiset. Lisäksi koodia on kommentoitu siellä, missä kommentteja tarvitaan. Kommentit on myös sijoiteltu koodiin nätisti (esim. pääasiassa funktioiden dokumentaatiomerkkijonoon).
- Bugittomuus: Myönnetään, jos ohjelmaa testaava assistentti ei saa ohjelmaasi hajoamaan tai toimimaan väärin (esim. sääntöjen vastaisesti) millään tavalla.
- Pelattavuus: Tämä maininta myönnetään pelille, jota pelatessa ei tarvitse kiroilla käyttöliittymän kanssa. Pelattavuuden pitäisi olla siis sujuvaa, ja pelitilanteen esityksen selkeä. Esim. siirron tekeminen pitäisi onnistua yhdellä tai kahdella lyhyellä syötteellä.
- Lisäominaisuus: Voidaan myöntää mm. hienosta lisäominaisuudesta, kurssilla esittämättömän työkalun järkevästä käytöstä tai vaikka jostain hauskasti toteutetusta ominaisuudesta.
Palautus¶
Arvostelutilaisuus¶
Kurssin hyväksymiseen vaaditaan, että opiskelija on käynyt työn tarkastaneen assistentin kanssa n. 15 minuutin pituisen keskustelun lopputyön tekemisestä kurssin viimeisellä viikolla. Ajanvaraus julkaistaan myöhemmin.