Forleden dag opstod et uventet problem i mine beregninger i Matlab: Der var ikke mere hukommelse tilbage, og mine beregninger stoppede derfor med nedenstående fejlmeddelelse.
That annoying moment when @MATLAB runs out of memory in a computation:-( #NeedMoreMemory #Programming #DTUFotonik pic.twitter.com/pC5DQv5eM9
— Jakob R. de Lasson (@Jakobrdl) 16. december 2013At hukommelse på et tidspunkt i løbet af mit ph.d. projekt bliver en udfordring, har været klart hele tiden, men at det skete allerede nu, mens jeg endnu regner på nanofotoniske strukturer, som effektivt er to-dimensionelle (2D), var en smule uventet. I det nye år skal jeg i gang med at udvikle en formalisme og kode, som kan bruges til at analysere realistiske, tre-dimensionelle (3D) problemer, f.eks. lysudbredelse og -udsendelse i fotoniske krystal membraner som den vist på billedet nedenfor. Denne udvidelse, fra effektive 2D til 3D beregninger, vil rent matematisk kun kræve mindre udvidelser, men mht. de numeriske beregninger vil udvidelsen være særdeles krævende, både hvad angår hukommelse og hastighed.
Lysudbredelse i fotonisk krystal membran.
Kilde: Nanofotonik Teori og Signalprocessering
Så det kan, i lyset af de hukommelsesproblemer jeg allerede i mine 2D beregninger er stødt på, godt betale sig at tænke både hukommelse og hastighed ganske meget ind i algoritmerne og flowet i den kode, jeg skriver. Herunder:
- Profiling: Profiling handler om at køre koden på et repræsentativt problem for at få et overblik over, hvilke dele af koden som kaldes ofte, og specielt hvor lang tid hver del af koden tager. Dette kan udgøre et udgangspunkt for, hvor i koden man bør investere sin tid og sine kræfter i at forbedre og optimere.
- Parallelisering: Parallelisering af de dele af koden, som kan køres uafhængigt, således at flere processer kan køres parallelt frem for sekventielt. Dette kan i Matlab bl.a. gøres ved at erstatte for-løkker med parfor-løkker, som netop udnytter, at beregningerne i hvert skridt af løkken kan laves uafhængigt og dermed parallelt. Jeg er i den forbindelse blevet gjort opmærksom på såkaldt Pinligt Parallelle Problemer, som min egen kode indeholder, og som det derfor er oplagt at parallellisere.
- Hukommelse: Jeg gemmer pt. meget data i hukommelsen, mens en beregning pågår, og dette har ikke hidtil været et problem. Men som beskrevet ovenfor er dette nu blevet en udfordring, og det er derfor værd at overveje, hvad som kan slettes undervejs i beregningerne, og om der er behov for at gemme data til harddisken. Det sidste har jeg hørt blandede ting om, og min egen oplevelse har været, at det er langsomt at skrive og læse til og fra harddisken. Men hvad gør man som alternativ, hvis man har mere data undervejs i beregningerne, end der kan være i hukommelsen? Beregningerne laves i øvrigt pt. på en computer med 32 GB RAM, hvilket altså ikke var tilstrækkeligt i ovennævnte beregning.
- Programmeringssprog: Jeg har i årevis skrevet kode og lavet simuleringer og analyser i Matlab. Men som beskrevet tidligere har jeg i dette efterår lært det basale i Python, og jeg har fået anbefalet at lave mine simuleringer i dette sprog frem for i Matlab - bl.a. fordi det er nemmere at skrive effektiv og hurtig kode. Indtil videre satser jeg på at fortsætte i Matlab, men mine erfaringer med Python dette efterår har dog været så positive, at jeg ikke afviser tanken om et skifte.
Så selvom jeg i mit første blogindlæg her på siden lagde op til, at jeg med udgangspunkt i teori og beregninger har færre praktiske udfordringer end folk, som arbejder i renrum og laboratorier, så er jeg bestemt ikke fritaget fra praktiske overvejelser om mit værktøj og mit "laboratorium".
Nu er det tid til at parallelisere, optimere og forbedre kode!
