The Waiting Game

A topographic map of the lunar south pole, as obtained using the LOLA instrument onboard LRO and reproduced from the JMars software package. Jasmeer Sangha, an MSc Candidate here at PVL, has been looking at code which simulates the movement of water particles in this region since having joined us from the University of Toronto in May.

By Jasmeer Sangha

During my four years of undergraduate work it became more and more apparent to me that my future would revolve around using programs to simulate various astrophysical phenomena. As I gained more experience, I was able to write and run more complicated scripts. Though, as these scripts became more complex the run time would increase. My first experience with run time issues came in my final year: I had been assigned a project where I would analyze a three body system which would destabilize after 100,000 years. The one caveat being that the time steps had to be very small for any close encounters between the two planets but then had to dynamically change to large steps when the planets were far apart. This dynamic time step ensured that the code would not need excessive amounts of time to run, still the code admittedly took a few hours. It was then that I learned the importance of efficiently scheduling around my code run times in order to troubleshoot issues and achieve the most runs in the minimum amount of time.

As one could infer, this first year working in York’s Planetary Science group has given me the opportunity to work with bigger and even lengthier projects. The first project I was exposed to was written by Professor Moores. The program simulated a particle jumping around on the spinning surface of the moon until it escaped, vapourized or landed in a crater where it was too cold to escape. This process was repeated for five million particles, resulting in a code that took well over a week. Luckily, I have not needed to run this time-intensive code, yet.



My current work is on a similar subject where, instead of just one, many particles are being simulated on the moon’s surface. Again this code is time-intensive, however my key dilemma is the randomness behind the code. A huge part of coding is the ability to run and rerun your code fixing small bugs until it is flawless and your results always point to the same answer. With codes that take this long to run, I find myself stuck between cutting the code short and possibly missing some glitches that slipped through the cracks, or alternatively, letting the code run for 50 plus hours only to find out that a single spelling error caused the code to shut down completely. Due to the random flight paths of these particles and the extreme unlikelihood that some criteria are met (falling into a trap), there are some branches of the code that need excessive amounts of runtime even before they are randomly activated. This means that running a shortened code renders certain occurrences virtually impossible. My only option is to go through the code with a keen eye, trusting myself, and hoping that the next few days of waiting will not be in vain.

We come to my current situation; the code I have written has been running for over two days now, I predict it will be done by the end of tomorrow. I have been frantically checking in on it, watching it count down to zero. So far, it seems I have caught all the errors hidden within, but only time will tell.