Labbrapport labb 4-2

From Carls wiki

Flödesschema

över huvudmomenten i programmet

Klassdiagram

Vi skapade vårt UML-klassdiagram i Umbrello, ett ganska kraschbenäget program. Tyvärr är det också väldigt roligt att använda. Vi har därför gjort så mycket vi kan för att få verkligheten att stämma illa överens med diagrammet, så att vi kan gå in och ändra det senare i Umbrello.

Funktionsgrafer

Image:Montecarlodiagramen.pdf

Potentiella energier

som funktion av antal steg (vdW, el och tot)

Image:Energidiagram.png

Mg²⁺ drog ifrån de andra i vår simulation. Den hittar snabbt ett stabilt tillstånd, kanske på grund av att den är starkt positiv och snabbt når ett stadium av låg energi i simulationen. Vi är dock försiktiga med att dra slutsatser om någon korrelation, för Ca²⁺ är segast i vår simulation.

Det faktum att grafen inte helt planade ut gjorde oss lite oroliga, så vi gjorde en extra lång körning av endast en jon.

Radiella distributionsfunktioner

för jon-syre-avstånden, ett för varje jon

Image:RDFdiagramLi-.png	Li⁺ Har en ganska hög första topp.
Image:RDFdiagramNa-.png	Na⁺ En typisk plot.
Image:RDFdiagramK-.png	K⁺ Ett första skal, och sedan inte mycket ordning.
Image:RDFdiagramRb-.png	Rb⁺ Liknar Cs+ fruktansvärt mycket. Har dock en något bredare förstatopp, men med ungefär samma höjd.
Image:RDFdiagramCs-.png	Cs⁺ Se Rb+.
Image:RDFdiagramMg2-.png	Mg²⁺ Den första toppen är jättehög.
Image:RDFdiagramCa2-.png	Ca²⁺ Den här har också en rätt hög första topp.
Image:RDFdiagramCl-.png	Cl^- Här ser vi flera väldigt tydliga skal, jämfört med i de andra graferna.

Källkod

Alla klassfiler i bokstavsordning, tillsammans med respektive klass Javadoc-sammanfattning.

Atom.java: This class provides a skeletal implementation of a physical atom, to minimize the effort required to create many similar classes of elements and ions.
Hydrogen.java: A model of a hydrogen atom in the Monte Carlo simulation.
Ion.java: A model of an ion in the Monte Carlo simulation.
IonThread.java: A Thread for running one Monte Carlo Simulation.
MonteCarloSimulator.java: The Monte Carlo Simulation wrapper class.
Oxygen.java: A model of an oxygen atom in the Monte Carlo simulation.
RDF.java: Main RDF class.
RDFHelper.java: Performs all the actual work in producing an RDF output.
Tools.java: A collection of methods which are useful in a Monte Carlo simultaion, but which don't fit into any specific class.
Universe.java: Simulates an ion soaked in water molecules.
Water.java: A model of a water molecule in the Monte Carlo simulation.

Kommentarer om körningarna

Hur många steg tar det innan energin stabiliseras?

Image:Longrun2.png

Vi gjorde en lite längre körning för att kontrollera att vi verkligen plockade data som hade stabiliserat sig. Vår slutsats blev att skattningen 3000 frames var ganska sund.

Hur stor är acceptanskvoten (andelen steg som accepteras)?

Eftersom vår långa körning innehåller mest data, utgick vi från den när vi beräknade acceptanskvoten. Då blir även avvikelsen på grund av att vi räknar med de tidiga värdena mindre.

awk '$1 ~ /Cl-/ {
  $4 = substr($4, 2, length($4)-2);
  $6 = substr($6, 2, length($6)-2);
  sum += $4+$6;
  frames++
}

END {
  print sum/frames/460
}' output.txt

Utdatafilen bifogas för fullständighets skull.

Diskussion

En kort diskussion om hur de valda jonerna skiljer sig baserat på distributionsfunktionerna.

Vilken jon är störst?

Vi utgår från x-koordinaten för första toppen i de olika jonernas grafer, och konstaterar att Cs⁺ och Cl^- har ungefär samma x-koordinat. Men det är jon-syreavstånden vi plottar, och för Cl^- ligger vätena närmare än syrena. Alltså är Cesium störst.

Vad är det som avgör höjden på den första toppen i distributionsfunktionen?

Hur många vatten i genomsnitt som lägger sig i första skalet, och hur väl de lägger sig på samma avstånd. Detta påverkas i sin tur av bland annat jonens laddningsstyrka.

Hur många toppar kan man urskilja?

Det varierar. På K⁺ urskiljer vi en topp och en dal, men inte mycket mer. Cl^- å andra sidan har väldigt många toppar.

Förklara hur man kan bestämma antalet vattenmolekyler i ett solvatiseringsskal.

Man beräknar, med en integral, arean under en topp (från en dal till nästa). Resultatet (som är en area i grafen men en enhetslös kvot i modellen) multipliceras med nummerdensiteten för en bulklösning och med volymen hos den ihåliga sfär som motsvaras av gränsradierna mellan vilka man integrerade.

Appendix A - Arbetslogg

Torsdag 050217

14:20 Vi har läst igenom labbinstruktionerna och den färdiga källkoden
14:35 Vi har gjort en skiss till flödesschema
14:51 Vi ställde frågor till labbhandledaren. Det känns bra
15:01 Vi har skapat klasserna Hydrogen.java och Oxygen.java
15:17 Varför är inte Atom abstrakt?
15:20 Det skulle den
15:38 Vi har ritat början till ett UML-diagram
16:05 Vi har skapat klassen Ion, lagt till medlemsvariabler och metoder i klasserna Atom och Ion, och refaktorerat alla klassnamn till att börja med versal
16:11 Vi tvekade lite inför att skapa getWaterMolecules() (och vad motsvarande variabel skulle heta)
16:25 Vi insåg att vdW_a och vdW_b inte ska vara final
16:47 Vi blev mystifierade av anropet till getRandom i Tools.randAng()
16:51 Vi skapade randomArray i Tools

Tisdag 050222

14:20 Vi har ändrat vattenmolekylarrayen till en ArrayList eftersom den läses in molekyl för molekyl i Universe.readPdb(). Vi har hittat på ett system med buffring i tempWater för att slippa skapa nya objekt hela tiden.
14:37 TODO: Skicka upp rotations- och translationslängd i interfacet
14:52 Vi lägger till en konstant radie i Universe
15:25 Vi skrev Universe.go(), Universe.createRandomArray() och Universe.isInside()
15:32 Vi skrev Universe.calculateEnergy()
15:57 Vi skrev Universe.calculateInteractions(Water, Water), potential(Atom, Atom) och Universe.calculateInteractions(Water, Ion)
16:20 Vi skapade Universe.BOLTZMANN och Universe.TEMPERATURE, och skrev Atom.distance() och Atom.squaredDistance()
16:26 Vi bytte namn på Universe.BOLTZMANN till Universe.MOLAR_GAS_CONSTANT
16:35 Vi bytte namn på Universe.MOLAR_GAS_CONSTANT till Universe.BETA, och tog bort Universe.TEMPERATURE

Onsdag 050223

14:25 Vi har fixat den mystiska delen i Universe.readPdb() och lagt till vårt eget system med en bitmask
14:32 Vi lade till ett anrop till readPdb() från Universe.go()
14:43 Vi har fått igång programmet lite. Insåg att vi måste nollställa found vid matchning
15:08 Vi hittade en gapande förbisikt i Water.Water(O, H, H): väte-arrayen skapades aldrig. Lade till så att den gjorde det
15:13 Vi ändrade parametertypen i Universe.writeFrame från Water[] till ArrayList för att slippa casta så mycket
15:42 Vi fick igång programmet. Nu ska vi fira med läsk
16:46 Vi tappade hela Universe.java på grund av att /home fylldes på datorerna i datorsalen. Det kommer att ta en liten stund att återskapa den. Vi har en backup från den 17 februari, dvs allt som vi har lagt till har gått förlorat

Torsdag 050224

09:58 Carl skrev om Universe.java ur minnet, ändrade ett par variabelnamn och lade till några ytterligare optimeringar

Fredag 050225

Lade till en header till utmatningen på skärm
Fixade lite med nollor i sekunderna och millisekunderna
Lade till så att förekomsten av parametrar kopplar förbi GUIt
Lade till parametrar för jonslag, antal snapshots, infil, trajektoriefil, samt energifil
Började skriva på en trådklass

Söndag 050306

Vi har fixat RDF_helper.java så att den läser in rätt antal frames.
Första testsimulationen hela vägen. Wohoo!
Nedanstående perlscript fixar en grundläggande plot

< rdf.out perl -pe 's/(\\d*.\\d*\\t*)(.*)/$2/;
$_ *= 10;
$_ = "*" x $_;
$_ .= "\\n"' | less

Tisdag 050308

15:24 Vi har joxat lite i RDF, upptäckt att Ion.java inte innehåller kod för att sätta värdena på van der Waals-konstanter och laddning, lagt till den. Vad som återstår: skriva ut pdb-fil, RDF-flödesschema, diagram över tre potentiella energier, som funktion av antalet steg, diagram över distributionsfunktionerna, ett per jon, kommentarer (Javadoc), kommentarer om körningarna (antal steg innan accepteras), acceptanskvoter (plotta?), kort diskussion om hur de valda jonerna skiljer sig baserat på distributionsfunktionerna (höjder på toppar) (hur bestämma antalet vattenmolekyler i ett solvatisertingsskal?). Kolla upp hur man använder invokeLater().
15:51 Vi sitter och ska lägga till kommandoradshantering i RDF.java.

Onsdag 050309

09:23 Vi fixade till slut formlerna (olikheten skulle vara åt andra hållet) och Boltzmanns konstant
10:30 Vi har lärt os hur man använder gnuplot (plot “energy.en” using 1 with lines) men vi skriver ut för många energivärden (för varje molekyl istället för för varje frame)
10:45 Det är något grymt fel med vattenmolekylerna. De springer och gömmer sig
12:04 Vi konstaterade att vårt knep med protected static inte funkade för att alla atomer blev väten
22:50 Jonathan har suttit hemma och (istället för att tentaplugga) efter att ha lagt en del tid på att komma på hur man ska snabba upp instoppandet av nya versioner av projektkoden i Eclipse ändrat ifrån ArrayList till array för watermolecules. Dock så valde jag att behålla ArrayListen vid inläsningen och sedan konvertera till en array efteråt
23:15 Fixade charge, vdW_a, vdW_b static var för sig i Ion, Oxygen och Hydrogen
23:20 Blev tvungen att fippla runt lite mer innan det här med static funkade. Nu finns det tre abstrakta getters i atom som sedan implementeras i Oxygen, Ion och Hydrogen där de returnerar returnerar respektive, för respektive klass, statiska variabler.

Torsdag 050317

22:30 Jonathan har nu gjort sista delen av javadocandet

Lördag 050326

14:58 Carl JavaDoc:ade. Hittade en skum förbisikt i Atom.java. Gjorde konstanterna i Hydrogen och Oxygen till final. Bytte namn på RDF_helper till RDFHelper. Gjorde ett stort antal publika metoder i MonteCarloSimulator, RDFHelper och Universe privata. Flyttade metoden percent från Universe till Tools. Lade till en exception i konstruktorn till Water

Appendix B - en ensam RDF-graf

Som vi gjorde men aldrig använde till någonting. Men den är väldigt fin. Jämför den gärna med den korta körningen av Cl^-.

Image:Longrun1.png

Cl^-, lång körning

Notera att den fjärde toppen här inte är lika tydlig.

Appendix C - Tips om objektorienterad Java-programmering

I all välmening.

Det är brukligt att ange klassnamn (och därmed även namnen på javafilerna) med stor första bokstav, stor bokstav för varje nytt ord, och utan understreck mellan orden.
När man som student får en prototypklass så är det skönt om det inte ligger skräp i den. Till skräp räknas:
- Autogenererade publika standardkonstruktorer till klasser som aldrig instansieras (till exempel för att de är hjälpklasser som Tools).
- Autogenererade kommentarer som inte tillför något och ändå ska ändras eller tas bort. Exempel:

/** Creates a new instance of Class */
public tools() {
}

Atom kunde ha varit en abstrakt klass eftersom den inte är tänkt att instansieras.
Exponera inte metoder som inte behöver vara publika i en klass.
- Det finns ingen anledning att göra read- och write-metoderna i Universe.java publika, eftersom den enda metod som använder dem är en metod i klassen.
- createComponents i MonteCarloSimulator och RDF ska inte kunna anropas utifrån.
JavaDoc-kommentarer skrivs i tredje person, inte i andra person. Exempelvis "Generates and returns", inte "Generate and return".
Statiska konstanter skrivs vanligtvis med uteslutande versaler och understreck.
Man behöver inte ha både en array och dess längd som parametrar till en metod, eftersom arrayen har en konstant datamedlem length.
Det anses som god form att använda else if för en serie av if-satser som testar ömsesidigt uteslutande fall.
Radius är latin, och betyder ursprungligen "eker" (som i ett cykelhjul) eller "stråle". Radii är den korrekta pluralformen, men det är inte korrekt att använda pluralformen om en enda radie. Att sfären har oändligt många lika långa radier räknas inte, eftersom det bara är längden vi är intresserade av.
Man skulle kunna använda TODO följt av vanlig text för indikera ännu inte skriven kod.
Man behöver inte, som i C, lägga alla deklarationer först i en metod. Man behöver inte separera deklaration och initiering av en variabel, om initieringen alltid är samma högerled.
- Det finns ingen anledning, i regel, att deklarera en iterationsvariabel utanför for-loopen.
Undvik tomma catch-block. Undantag funkar bäst när de tas på allvar i bägge ändar. Lägg åtminstone till en kommentar om varför undantaget inte tas om hand; någonting har ju gått fel.

Slutligen: tack för att ni beslutade er för att använda Eclipse i programmeringslabben. Vi har båda fått ett mycket gott intryck av utvecklingsmiljön som vi inte hade fått annars.

Retrieved from "http://www.masak.org/carl/w/index.php/Labbrapport_labb_4-2"