With the nature of my project being mostly computational, I had anticipated running into issues with coding (as one always does). Programming has never really been my strong point – I much prefer to get given a good old pen and paper and be told to solve an equation – but I have always acknowledged that it is an extremely powerful tool, and one without which modern physics research simply wouldn’t be possible.

Although having done little to no coding before starting university, I was confident that I had gained enough experience over my past two years of studies to be able to solve any issues I had with relative ease. The project was to make use of S4 software – developed to solve Maxwell’s equations in layered structures, and thus produce simulations of the interactions of EM waves with different surfaces – and seeing that it was (allegedly) programmable in Python put my mind at ease.

At that point, I thought my biggest challenge would be to understand the theory of nonlinear optics and ENZ metasurfaces, and I was expecting to spend much of my time reading scientific papers on the topic in the early stages of the project. The opposite turned out to be true.

First day of the project: I navigate my way to the S4 website to begin the installation process. “This shouldn’t take me long,” I thought. After all, how hard is it to install a software on your computer? Not too easy, as it turned out. The installation presented a multitude of problems, some of which were quick fixes, but the majority of which left me stumped. This included me trying to navigate through files in an Ubuntu terminal for the first time, as well as having to install several “optional” packages (which in reality are very much needed for the software to run correctly) to the main software with varying degrees of success.

Moving on from this rocky start, I decided that the best course of action would be to use the programming language Lua instead of Python to code for the software. S4 was originally developed with Lua, and so is predisposed for its use, whereas a Python extension would need to be installed to code with the latter (this I tried, and failed, to do). Starting out, I was wary of this language, not just because I hadn’t encountered it before, but because there are significantly fewer troubleshooting resources available for it than for more popular programming languages.

Indeed, it was vastly different to what I had grown used to, and I had greatly underestimated the difficulty I would have in making my code work correctly. A glaring example of this was my attempt to code a polynomial function to represent a materials’ dispersion, for which I planned to use an array. Having grown accustomed to working with in-built commands, I expected to find a similar Lua command to construct said array. To my great dismay no such command exists, and I had to resort to taking long-winded and contrived way to get around this frustrating inconvenience.

Overall, I had planned to spend no more than a week of my project schedule on the installation of the software and my familiarisation with it. In reality, it took me closer to three weeks to complete fully. Thankfully, I still got the main part of the research finished in time, but I wonder whether I could’ve done more had I not been hindered by computational problems. This experience has really shown me that I should approach coding with more patience, to not underestimate its difficulty, and not get bogged down too much if the code doesn’t work the way it should initially, as it always works itself out in the end. But in the meantime, I think I’d rather stick with physical experiments when given the chance!

I would like to thank my supervisor, Dr. Sebastian Schulz, and his PhD student, Laura Wynne, for supporting me throughout this project and providing their valuable insight and help. I would also like to thank Lord Laidlaw and the Laidlaw Foundation for this incredible opportunity, and the great research experience I gained with it.